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1.0  EXECUTIVE  SUMMARY 


1.1  SEA  STRIKE  INITIATIVES 

Fleet  Battle  Experiment  KILO  (FBE-K)  contained  two  primary  Sea  Strike  initiatives: 

Initiative  #  1 :  Refinement  of  Commander  Seventh  Fleet  Joint  Fires  Network  Concept  of 
Operations  (C7F  JFN  CONOPS)  and  Commander,  Seventh  Fleet  /  USS  BLUR  RIDGE  Time 
Sensitive  Targeting  Standard  Operating  Procedures  (C7F  TST  SOP). 

Initiative  #2:  Establishment  and  examination  of  requirements  for  utilization  of  a 
Distributed  Maritime  Sensor  and  Fires  network  that  integrates  a  Coalition  engagement  node 
within  that  network. 

In  addition  to  CONOPS  evaluation,  a  major  component  of  Initiative  #1  was  for  NWDC  and  C7F 
to  examine  and  document  theater  support  requirements  inherent  to  standing  up  a  Joint  Fires 
Network  (JFN)  architecture  in  a  forwarded  deployed  theater.  JFN  was  to  be  tested  in  support  of 
JTF  TST  operations.  Initiative  #2  was  to  test  both  the  coalition  infonnation  filter  within  the 
maritime  engagement  grid  and  processes  for  Coalition  participation  in  TST. 


1.2  OVERVIEW 

FBE-K  was  conducted  in  conjunction  with  the  USPACOM  exercise  TANDEM  THRUST  03 
(TT03),  which  consisted  of  two  segments,  a  Command  Post  Exercise  (CPX)  and  a  Field  Training 
Exercise  (FTX).  The  centerpiece  of  this  effort  was  the  C7F  flagship,  USS  BLUE  RIDGE  (LCC- 
19).  C7F  (as  designated  by  COMPACFLT)  has  the  requirement  to  use  the  flagship  as  a 
deployable  host  for  the  Joint  Forces  Commander,  and  designated  Component  Commanders  and 
staffs  in  theater.  C7F  was  embarked  in  LCC-19  as  the  CJTF  with  an  embarked  JFACC  element 
to  plan  and  execute  OPLAN(s)  and  contingency  operations. 

The  Sea  Strike  initiatives  focused  on  the  command  and  control  (C2)  processes  centered  at  the 
Joint  forces  Commander  and  Component  Commander  levels.  The  principal  TST  C2  elements 
were  JFACC  Afloat  and  the  JFMCC  XP  Cell.  Coalition  command  was  located  on  the  virtual 
ANZAC  and  it  coordinated  with  the  XP  cell. 

TST  processes  were  to  be  supported  by  C7F’s  employment  of  the  Joint  Fires  Network  (JFN) 
suite  installed  aboard  BLUE  RIDGE.  It  included  Joint  Services  Imagery  Processing  System- 
Navy  (JSIPS-N),  Precision  Targeting  Workstation  (PTW),  and  the  recently  installed  Army  Deep 
Operations  Coordination  System  (ADOCS)  and  Tactical  Exploitation  System-Navy  (TES-N). 
TES-N  was  in  the  Joint  Intelligence  Center  (JIC)  and  ADOCS  tenninals  were  in  the  JIC,  the 
Joint  Operations  Command  Center  (JOCC)  used  by  the  JFACC,  and  XP  cells.  TST  processes  to 
be  tested  were  allocation/reallocation  of  weapons  and  sensors,  target  assignments,  and  fire- 
mission  deconfliction. 
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Considerable  difficulties  in  fulfilling  Sea  Fire  Initiative  objectives  were  experienced  during 
experiment  execution  due  to  reduced  JFACC  manning  and  equipment  problems.  Because  of 
this,  the  experiment  and  exercise  became  decoupled,  with  the  exercise  proceeding  as  planned  but 
with  little  or  no  support  from  JFN  or  the  experiment  personnel.  The  results  reported  here  are 
from  what  was  accomplished  by  the  experiment  as  essentially  a  separate  entity. 

There  was  not  an  approved  C7F  JFN  CONOPS  or  C7F  TST  SOP  available  to  test  during  the 
experiment.  NWDC  provided  draft  documents  based  partly  on  the  PACAF  Draft  TST  SOP  and 
NFN  TACMEMO.  Because  of  equipment  problems,  lack  of  operator  training  on  the  new 
systems,  and  little  operator  familiarity  with  TST  SOPs  and/or  TTPs,  no  TST  CONOPS  or  SOP 
evaluation  could  be  perfonned.  Rather,  the  experiment  served  to  introduce  the  SOPs  and  TTPs 
to  Fleet  personnel.  Development  of  C7F  TST  SOP  requires  development  of  operational  (N3) 
procedures  and  coordination  with  Fleet  staff. 


1.3  FIRES  INITIATIVES  PRINCIPAL  FINDINGS 

Findings  obtained  for  the  Fires  Initiatives  are  qualitative  rather  than  quantitative,  and  cover 
broad  aspects  of  TST  processes  rather  than  specifics.  Training  on  some  of  the  component 
systems  was  conducted  and  Fleet  personnel  acceptance  of  the  systems  and  the  possibilities  they 
present  for  improved  operations  was  documented.  Possible  TST  process  improvements  were 
obtained  rather  than  a  detennination  of  what  process  and  system  combinations  do  and  do  not 
work. 

Substantial  specific  information  was  obtained  on  hardware  system  perfonnance.  FBE-Kilo 
introduced  the  use  of  JFN,  including  TES-N,  to  Seventh  Fleet  personnel.  Definitive 
recommendations  for  needed  system  and  process  improvements  before  JFN  can  achieve  the 
needed  level  of  performance  for  TST  have  been  identified. 

1.3.1  System  Improvements 

FBE-K  produced  a  significant  number  of  recommendations  for  system  improvement.  A  number 
of  these  had  already  been  identified  in  previous  experiments.  No  further  operational 
experimentation  should  be  conducted  with  JFN  without  first  making  these  improvements. 

Tactical  Exploitation  System  -  Navy  TES-N  has  a  number  of  powerful  tools  (some  of  which 
are  unique  to  TES-N)  that  potentially  could  be  of  great  use  to  naval  forces  involved  in  TST. 
FBE-K  reconfirmed  that  TES-N  remains  a  very  complex  and  developmentally  immature  system, 
with  extremely  limited  interfaces  to  other  C4I  systems  that  are  critical  to  TST.  Major  advances 
are  needed  for:  Interface  with  ADOCS  or  other  TST  Command  and  Control  system;  Interface 
with  GCCS-M;  Interface  to  PTW  and  any  external  target  folder  applications;  Handling  of  ISR 
video  and  platform/sensor  telemetry;  SCI  COMINT  analysis  tools  and  SCI-to-GENSER 
connectivity  via  ISSE  Guard 

ADOCS  as  the  TST  Command  and  Control  System  TST  C2  system  requirements  should  look 
beyond  the  extensive  typing  input-output  approach  in  ADOCS  and  its  matrix  displays  for  TST 
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coordination  status.  Many  of  the  C2  processes  in  ADOCS  are  complicated,  difficult  to  define 
unambiguously,  challenging  to  train,  and  highly  dependent  on  internet  chat  and  voice 
elaboration. 

ADOCS  is  an  Advanced  Concept  Technology  Demonstration  (ACTD),  but  the  challenges 
evident  in  FBE-K  raise  the  question  if  the  ADOCS  approach  is  the  right  concept  to  be  applied  to 
Joint  Time  Sensitive  Targeting.  Because  of  the  time-sensitivity  of  the  targets  and  because  it  is  at 
the  tactical  level  of  war,  some  of  the  functionality  built  into  air  defense  command  and  control 
systems,  such  as  AEGIS  or  AWACS  should  be  examined  for  applicability  to  ground  TSTs.  If 
ADOCS  is  to  be  used,  the  improvements  listed  below  are  needed. 

The  ADOCS  Managers  exhibit  inconsistencies  and  latencies  that  at  times  inhibit  and 
occasionally  defeat  the  TST  engagement  process.  Problems  observed  include:  Missions  appear 
in  some  ADOCS  workstations  but  not  others.  The  coordination  block  status  can  be  different  at 
different  ADOCS  workstations.  The  mission  status  (e.g.  fired  or  not  fired)  may  be  different  in 
the  Mission  Coordination:  Fires  and  JTST  Managers.  Mission  status  as  determined  from  the 
Mission  History  may  not  agree  with  the  status  in  the  Mission  Coordination:  Fires  display.  Some 
events  are  missing  from  the  Mission  Histories.  Troubleshooting  and  fixing  these  inconsistencies 
is  required. 

A  TST  C2  System  needs  functionality  for  automatically  and  unambiguously  keeping  track  of 
targets  that  move,  re-position,  and  change  status.  ADOCS  needs  functionality  added  for  such 
targets,  i.e.,  dynamic  target  position  information  rather  than  static  data  fields.  Concurrently, 
functionality  is  needed  for  automatic  updating  and  alerting  of  decision  makers  and  engagers. 
Functionality  is  also  needed  for  other  critical  changes  in  target  status,  such  as  missiles 
transitioning  from  stowed  to  erected  positions.  This  may  require  dynamic  updating  of  target 
description,  and  certainly  needs  automatic  updating  and  alerting  of  decision  makers  and  target 
engagers. 

Several  Human-System-Interaction  (HSI)  improvements  are  needed.  Means  are  needed  for 
target  prioritization,  pending  task  notification,  standardized  critical  task  color-coding.  These 
may  appear  to  be  trivial  matters,  but  the  current  situation  is  such  that  HSI  plays  a  significant  role 
in  hindering  TST  processes  and  lengthening  the  timeline.  Color-coding  isn’t  merely  a  training  or 
doctrine  issue.  Because  it  is  being  used  for  coordination  of  time-critical  tasks,  the  colors  or 
symbols  used  should  be  engineered  to  be  much  more  intuitive  than  they  are.  Ideally,  as  intuitive 
as  real  traffic  lights  so  that  people  will  respond  predictably,  and  quickly. 

1.3.2  Fires  TTP 

Frequent  and  serious  departures  from  the  Fires  TTP  were  partly  due  to  player  confusion  or 
misunderstanding  regarding  procedures  and  partly  caused  by  ADOCS  displays  latencies  and 
inconsistencies.  Observed  departures  in  ADOCS  coordination  block  actions  included:  required 
TTP  actions  were  not  being  taken,  actions  taken  but  not  by  the  responsible  node,  actions  taken 
that  are  undefined  by  the  TTP  (hence  meaningless),  and  actions  executed  in  the  wrong  sequence. 
A  concerted  effort  is  needed  to  develop  adequate  TTPs  and  train  to  them. 
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1.4  COALITION  INITITIVE  PRINCIPAL  FINDINGS 


The  two  processes  in  place  for  multilevel  and  multinational  security  of  information  transfer  were 
Radiant  Mercury  Gold  (RMG)  for  automated  message  transfer  and  a  manual  screening  process 
for  chat  (e-mail-like)  messages.  Situations  where  these  measures  actually  inhibited  proper 
information  flow  were  inherent  in  the  design  of  the  network.  ADOCS  coordination  messages 
were  not  recognized  by  RMG  and  there  was  an  inherent  delay  caused  by  having  chat  messages 
manually  reviewed  for  security  before  being  passed. 

It  was  not  possible  to  assess  the  adequacy  of  security  procedures  and  whether  they  enabled  or 
hindered  Joint  and  Coalition  planning  because  there  was  no  distributed  planning  cell  with 
exclusive  responsibility  for  developing,  reviewing,  distributing,  and  modifying  daily  planning. 
Discrepancies  were  observed  between  timing  infonnation  in  the  daily  Air  Tasking  Order  (ATO) 
and  the  weapon-target  pairing  assistance  provided  by  experimental  ADOCS  on  the  U.S.  side. 
These  problems  were  never  resolved,  so  cases  where  Coalition  participants  were  included  in 
planning  processes  could  not  yield  conclusive  information. 

1.4.1  Coalition  Fires  TTP 

The  most  significant  issue  encountered  by  Coalition  was  the  absence  of  a  clearly  defined, 
tactical  level,  step-by-step,  C2  process  for  coordination  of  fires.  Creation  of  a  step-by-step 
process  for  fires  coordination  part  way  through  the  FTX  was  too  late  and  discussion  was  focused 
on  understanding  processes  rather  than  on  improving  it.  Operator  confusion  at  ANZAC  and  at 
the  Coalition  Cell  was  high,  which  lead  to  lengthy  chat  and  VoIP  communications  for 
clarification. 

The  lack  of  SOPs  for  the  fires  coordination  process,  together  with  the  continued  presence  and 
efforts  to  resolve  ADOCS  integration  issues  essentially  undennined  all  unit  and  higher-level 
training.  The  result  was  Coalition  team  on-going  confusion  in  the  fires  coordination  process. 

1.4.2  ADOCS  and  RMG  Rule  Sets  and  Interface 

RMG  bridged  the  security  boundary  between  the  SECRET  US  NOFORN  and  SECRET 
AUSCANUKUS  releasable  networks.  GCCS-M  COP  was  transmitted  effectively  across  RMG. 

Due  to  budget  and  time  constraints  for  RMG  accreditation,  a  previously  approved  rule  set  was 
used.  It  did  not  use  the  latest  message  format  used  in  ADOCS  so  that  exchange  prototype 
messages  generated  by  ADOCS  could  not  be  recognized  by  RMG.  Thus,  not  all  of  the  data  sent 
through  RMG  from  SECRET  US  NOFORN  ADOCS  was  transferred  to  the  Coalition  network. 

The  RMG/ ANZAC  ADOCS  interface  had  problems.  Coordination  block  problems  resulted  in 
ANZAC  transmitting,  by  IRC,  to  the  BLUE  RIDGE  desired  coordination  block  actions  that  were 
then  inserted  in  the  ANZ  coordination  block  by  a  BLUE  RIDGE  ADOCS  operator.  No  ANZAC 
GISRC  target  nominations  were  found  in  the  ADOCS  FBE  net  servers;  reason  unknown. 


1.4.3  Chat,  Voice  Over  IP,  and  Sneaker-Net 

Radiant  Mercury  Guard  was  used  to  filter  and  transfer  structured  messages.  To  exchange 
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unstructured  messages  (Chat,  e-mail,  VoIP,  web  pages)  between  U.S.  and  Coalition  systems,  a 
human-in-the-loop  ‘air  gap’  (Sneaker-Net)  was  utilized.  Information  from  U.S.  was  reviewed 
and  relevant  infonnation  for  Coalition  was  transferred  across  the  boundary.  Transcribing 
messages  between  the  XP  cell  on  BLUE  RIDGE  and  the  ANZAC  command  team  in  Fem  Hill 
led  to  some  ambiguity  in  communication.  The  air  gap  introduced  latencies  of  about  seven 
minutes  and  was  manpower  intensive.  An  automated  filter  (e.g.  ISSE  Guard)  is  required. 

VoIP  was  of  high  quality  after  network  issues  were  resolved.  It  was  effectively  utilized  for 
technical  troubleshooting  and  demonstrated  a  potential  for  use  for  tactical  coordination. 


1.5  ORGANIZATION 

Time  Critical  Targeting  Functionality  Afloat  TCTF  is  a  USAF  program  that  outlines  C2 
requirements  and  systems  for  conducting  TCT  operations.  The  X-Ray  Papa  cell  was  an  excellent 
test  case  for  familiarizing  the  Fleet  with  the  TCTF  concept.  The  USN  needs  to  refine  this 
concept  to  support  joint  and  maritime  forces  for  a  JFC  Afloat  configuration.  The  TCTF  Afloat 
concept  should  be  a  starting  point  for  future  Sea  Strike  initiatives. 

X-Ray  Papa  and  Maritime  Component  Time  Sensitive  Targeting  The  X-Ray  Papa  cell 
identified  a  time  sensitive  targeting  gap  at  the  maritime  component  level  that  needs  to  be 
addressed.  JFMCC’s  conduct  of  broad  scale  TST  operations  that  are  integrated  with  other 
components  is  beyond  the  traditional  role  of  the  Bravo  Papa.  A  staff  function  at  the  operational 
level  (JFMCC)  that  supports  TST  prosecution  is  required.  This  effort  should  be  integrated  with 
the  TCTF  effort  described  above  to  help  identify  maritime  TST  command  and  control 
requirements  of  the  future. 


1.6  COP  ISSUES 

A  true  “Common”  Operational  Picture  is  non-existent.  In  FBE-K,  a  COP  was  not  maintained  to 
a  level  required  to  support  ISR  and  JFN  in  support  of  TST.  Different  pictures  always  existed  in 
GCCS-M,  ADOCS,  and  TES-N. 

In  spite  of  this,  some  COP  goals  were  achieved;  by  the  end  of  FTX,  all  of  the  simulated  Blue  ISR 
assets  active  in  M&S  were  simultaneously  displayed  on  BLUE  RIDGE’s  GCCS-M  COP  with 
appropriate  labels  (e.g.,  two  ISR  UUVs,  two  Predator  UAVs,  one  U-2).  This  was  the  first  time 
that  this  has  happened  in  an  FBE. 

Exchange  of  TST  infonnation  between  TES-N  and  GCCS-M  remains  a  problem. 

TST  location  output  to  COP  The  TST  nomination  analyst  used  TES-N’s  interface  to  GCCS-M 
to  input  the  target  into  the  COP  as  a  track  to  assist  in  tracking  the  TST  while  waiting  for  it  to  be 
engaged.  This  procedure  only  worked  for  two  days  at  the  same  rudimentary  and  sub-optimal 
level  at  which  it  was  working  for  MC02/FBE-J  (the  new  TES-N  version  5.0  provided  no 
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improvement).  For  the  remainder  of  FBE-K  it  was  functionally  inoperative. 


GCCS-M  COP  Tracks  into  TES-N  ITD  It  was  also  planned  that  GCCS-M,  COP  tracks  be  sent 
from  GCCS-M  to  TES-N.  The  objective  was  to  provide  a  richer  context  of  contacts,  tracks,  Blue 
ISR  asset  locations,  etc.,  in  TES-N  for  the  analysts  trying  to  find/ fix  TSTs.  TES-N’s  incoming 
“Message  and  Data  Log”  showed  a  good  number  of  incoming  tracks  from  GCCS-M,  but  those 
tracks  did  not  parse  into  the  TES-N  ITD.  When  GCCS-M  tracks  coming  into  TES-N  were  able 
to  be  brought  up  on  the  ITD  it  did  not  display  any  track  labels.  (GCCS-M  tracks  in  TES-N’s 
ITD  appeared  in  their  proper  locations  but  the  symbols  do  not  have  any  labels  associated  with 
them  (e.g.,  no  track  names),  making  them  all  but  functionally  useless  to  the  TST  team.) 


1.7  TECHNOLOGY 

FBE-K  revealed  a  number  of  equipment  problems.  System  perfonnance  and  compatibility  issues 
are  hindering  obtaining  operational  benefits  that  should  be  realized  from  some  of  the  new 
systems.  Recommendations  contained  in  this  report  will  have  an  impact  on  hardware  system 
program  management,  if  implemented.  Some  of  these  issues  are  long  standing  and  should  be 
addressed  before  further  experimentation  with  these  systems  is  carried  out.  Details  are  contained 
throughout  the  report,  particularly  in  Sections  6.8,  6.9,  6.11,  and  Appendices  C  and  E. 

Shipboard  System  Specifications  USS  BLUE  RIDGE  has  a  10  mb  switch  backbone  that  is 
connected  via  155  mb  links.  This,  along  with  inconsistent  network  card  setting  hindered 
ADOCS  use.  Standard,  shipboard  LAN  configurations  that  support  ADOCS  need  to  be 
established  for  switch,  link,  and  network  card  settings  on  these  machines.  Hardware  limitations 
may  require  platforms  to  set  up  multi-server  configurations  to  reduce  the  effect  of  less  modern 
network  backbones.  ISNS  ADOCS  standards  should  be  set  prior  to  install  and  configured 
accordingly. 

ADOCS  Changes  Many  recommended  changes  to  ADOCS  were  compiled  during  FBE-K. 

These  are  for  providing  adequate  support  to  TST  within  currently  existing  C2  capability 
requirements.  New  processes  that  are  being  experimented  with  will  undoubtedly  introduce 
additional  requirements.  Improvements  are  needed  to  enhance  situational  awareness,  e.g.,  target 
status  and  alerting  for  required  actions.  Hot  links  are  needed  to  provide  easy  access  to  important 
background  information  such  as  ROE,  TST  priorities,  and  target  folders. 

JFN  interaction  with  ADOCS  ATI.ATR  target  nomination  to  JFN  was  incomplete  and  not 
usable.  This  problem  was  identified  over  2  years  ago,  still  exists,  and  needs  to  be  fixed. 

Detailed  ADOCS-JFN  testing  should  be  completed  in  the  lab  and  needed  modifications  made 
rather  than  waiting  for  another  experiment. 

The  TST  nomination  analyst  used  TES-N  to  create  a  target  nomination  message  (in  USMTF 
“ATI.ATR”  format),  and  sent  that  nomination  message  (via  SMTP)  to  the  ADOCS  server  on 
BLUE  RIDGE,  and  to  the  TST  Target  Folder  server  at  NWDC.  Considerable  effort  was  required 
to  get  all  systems  interoperating  correctly:  TES-N  LAN,  ship’s  LAN/Exchange  server,  FBE-K 
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WAN  and  Exchange  servers,  and  ADOCS  mail  server.  Once  set  up  properly  the  process  worked 
well. 

Inconsistencies  existed  in  how  target  nominations  were  handled  by  ADOCS  and  how  they  were 
showing  up  in  the  TST  Target  Folder  server.  The  fault  was  in  both  TES-N  and  ADOCS,  with 
inconsistencies  in  target  line  usage.  ADOCS  turned  around  an  ATI.ATR  with  fields  out  of  order 
and  truncated. 

Images  related  to  target  nominations  to  PTW  for  aim-point  refinement  Images  (e.g.,  video 
“chips”  showing  the  TST)  were  to  be  attached  to  outgoing  target  nominations,  and  the 
nomination  sent  simultaneously  to  ADOCS,  the  TST  Target  Folder,  and  PTW.  The  version  of 
PTW  used  on  BLUE  RIDGE  could  not  receive  and  parse  ATI.ATR  messages  (i.e.,  did  not  have 
the  DTMS  software  used  in  MC02/FBE-J).  TES-N  does  not  allow  images  to  be  attached  to 
outgoing  ATI.ATRs. 


1.8  Equipment  Casualty  Modes 

A  TST  C2  System  needs  to  have  reliable  alternative  modes  of  operation  and  more  graceful 
degradation  than  is  currently  available  with  open-architecture  LANs  and  internet-style  networks. 
Most  legacy  combat  systems  have  casualty  modes  and  some  have  several  levels  of  casualty 
modes.  The  down-time  and  network  problems  encountered  in  FBE-K  may  not  be  atypical  of 
what  might  occur  in  the  real  world  with  leading  edge  technologies,  pushing  the  envelope,  built 
on  open- architecture  machines  and  networks. 


1.9  Pre-Experiment  Testing  and  Go/No-Go  Decision 

Some  of  the  difficulties  encountered  in  FBE-K  were  known  prior  to  the  experiment.  Equipment 
problems  were  uncovered  when  tests  were  run  on-site  immediately  before  embarkation.  The 
question  arises  as  to  whether  an  experiment  should  be  conducted  under  these  circumstances.  An 
FBE  naturally  build  up  a  momentum  toward  execution  that  is  almost  irresistible.  There  is  no 
process  to  decide  whether  or  not  to  execute  an  experiment  or  to  scale  it  back  to  a  level  that  can 
be  achieved.  Two  recommendations  are  germane  to  this  issue.  First,  establish  a  time  at  least  six 
weeks  prior  to  an  experiment  by  which  all  equipment  to  be  used  is  tested  and  demonstrated  to 
operate  adequately  to  meet  experiment  goals.  If  that  level  is  not  achieved,  the  equipment  cannot 
be  fielded.  Second,  establish  a  process  for  periodic  review  of  experiment  status.  At  each  review, 
demonstration  that  sufficient  progress  has  been  achieved  to  warrant  continuing  must  be  made  or 
an  automatic  no-go  or  scale-back  decision  follows. 
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2.0  INTRODUCTION 


The  following  italicized  descriptions  are  taken  directly  from  the  Navy  Warfare  Development 
Command  (NWDC)  FBE  KILO  Experiment  Plan. 

Fleet  Battle  Experiment  K  (FBE  K)  will  be  conducted  in  the  spring  of 2003,  the  11th  experiment 
in  the  FBE  series.  It  will  be  conducted  in  conjunction  with  the  USPACOM  tier  1  level  exercise, 
Tandem  Thrust  03  (TT03).  TT03  is  comprised  of  two  events,  a  Command  Post  Exercise  (CPX) 
and  a  Field  Training  Exercise  (FTX);  FBE  K  will  participate  in  both  events. 

As  part  of  FBE  K,  many  of  the  Experiment ’s  initiatives  will  focus  on  the  command  and  control 
(C2)  processes  centered  at  the  joint  force  level.  A  primary  goal  is  to  apply  the  concepts  of 
Network  Centric  Warfare  (NCW)  to  the  processes  used  to  support  a  Joint  Task  Force  (JTF)  staff 
and  a  Joint  Forces  Air  Component  Commander  (JFACC)  while  they  are  embarked  aboard  a 
Joint  Fires  Network  (JFN)  equipped  command  platform  (USS  BLUE  RIDGE  LCC-19).  FBE  K 
will  concentrate  on  the  allocation  /  reallocation  of  both  weapons  and  sensors,  target  assignment, 
and  fire  mission  deconfliction  in  support  of  the  JFACC  execution  of  Time  Sensitive  Targeting 
(TST)  operations  at  the  joint  force  and  component  level.  FBE  K  will  use  a  common  set  of 
automated  tools  and  common  system  architecture  aboard  the  USS  BLUE  RIDGE  that  enables 
effective  TST  C2  and  joint  task  force  coordination.  This  flexible  Joint  Fires  Initiative  C2 
architecture  is  designed  to  increase  the  speed  and  tempo  at  which  the  JTF  as  a  whole  can 
conduct  TST  operations. 

In  support  of  these  goals,  there  were  two  Sea  Strike  Initiatives,  which  we  have  named  "TST 
Processes"  and  "Coalition"  for  the  purposes  of  this  report.  The  Initiative  Statements  for  each  in 
the  Experiment  Plan  are: 

TST  Processes  Initiative.  Refinement  Of  Commander,  Seventh  Fleet  Joint  Fires  Network 
Concept  of  Operations  (C7F  JFN  CONOPS)  and  Commander,  Seventh  Fleet  /  USS  BLUE 
RIDGE  Time  Sensitive  Targeting  Standing  Operating  Procedures  (C7F  TST  SOP). 

Coalition  Initiative:  Establishment  and  examination  of  requirements  for  utilization  of  a 
Distributed  Maritime  Sensor  and  Fires  network  that  integrates  a  coalition  engagement  node 
within  that  network. 

In  October  2002  the  C7F  Flagship,  USS  BLUE  RIDGE,  received  a  TES-N  installation.  Upon 
installation  completion,  the  JFN  Program  Office  developed  a  draft  Concept  of  Operations 
(CONOPS)  tailored  to  C7F  needs.  That  draft  CONOPS  was  not  adapted  by  C7F.  Instead,  C7F 
desired  to  develop  procedures  based  on  the  Pacific  Air  Forces  (PACAF),  Joint  Forces  Air 
Component  Commander  (JFACC)  Afloat,  Time-Critical-Targeting  (TCT)  Standard  Operating 
Procedures  (SOP).  C7F  requested  NWDC  assistance  in  exercising  JFN  aboard  Blue  Ridge  and 
refining  C7F  Joint  Time  Sensitive  Targeting  (TST)  procedures. 
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The  emphasis  during  the  TT03  FTX  was  on  collaboration  and  coordination  between  CJTF  ISR 
Operations  and  multiple  components,  and  on  tools  to  speed  coordination  and  enable  common 
situation  awareness  of  TST  status.  Specifically, 

■  Emphasize  collaboration/coordination  between  CJTF/JFACC/JFMCC  TST  elements 

■  Exercise  Army  Deep  Operations  Coordination  System  (ADOCS)  network  between  CJTF 
and  multiple  components 


2.1  FIELD  TRAINING  EXERCISE 

The  purpose  of  the  Field  Training  Exercise  (FTX)  is  to  train  a  U.S.  Pacific  Command  Joint  Task 
Force  (JTF)  under  Commander,  U.S.  Seventh  Fleet  operating  as  the  Commander  of  the  JTF.  This 
was  done  within  the  structure  and  scenarios  of  Tandem  Thrust  03.  The  exercise  scenario  was 
defense  of  a  fictitious  island  nation  Guppie  against  an  aggressor  island  nation  Piranha.  The 
scenario  was  complicated  by  the  presence  of  military  forces  from  the  fictitious  nation  of  Orca, 
which  was  sympathetic  to  Piranha  but  not  overtly  engaged  in  aggressive  action. 

U.S.  Joint  Task  Force  tasking  included: 

■  Secure  SLOCs/ALOCs  within  the  Joint  Operating  Area 

■  Forcible  entry.  Re-take  friendly  territory  seized  by  aggressor  nation 

■  Conduct  Humanitarian  assistance  operations 

■  Fortify/defend  friendly  nation(s) 

■  Establish  bases  for  future  combat  operations  against  aggressor 

■  Eliminate  aggressor’s  ability  to  threaten  region 

The  command  structure  for  the  exercise  was: 

CJTF  -  COMSEVENTHFLT  embarked  USS  BLUE  RIDGE 
JFMCC  -  CTF  70  embarked  USS  CARL  VINSON 
Theater  ASWC  -  CTF  74  Yokosuka  Japan 

Expeditionary  Strike  Group  (ESG)  Commander  -  embarked  USS  ESSEX 
JFACC  -  PACAF  0-6  embarked  USS  BLUE  RIDGE 

-  JFACC  TST  Cell  0-4  embarked  USS  BLUE  RIDGE 
JSOTF  -  SOCPAC  0-6  COMNAVFORMARIANAS  Guam 
JFLCC  -  embarked  USS  BLUE  RIDGE 

There  were  extensive  live  forces  participating  in  the  overall  TT03  FTX.  However,  the  live 
forces  did  not  participate  in  the  Fires  Initiative  of  FBE-K,  and  so  they  are  not  listed  in  this  report. 


2.2  TST  PROCESSES  INITIATIVE 

The  purpose  of  the  Fires  Initiative  was  primarily  to  determine  the  support  to  TST  that  can  be 
provided  by  JFN.  The  TES-N  portion  of  JFN  resided  within  and  was  utilized  by  the  Joint 
Intelligence  Center  (JIC).  ADOCS  was  to  be  used  for  the  engagement  COP  primarily  in  the 
Joint  Air  Operations  Center  (JAOC)  on  the  Blue  Ridge. 
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Initiative  number  one’s  primary  goal  is  to  support  C7F  in  refining  and  validating  its  C7F  JFN 
CONOPS  /  C7F  TST  SOP.  This  initiative  will  attempt  to  (to  the  maximum  extent  possible) 
define  JFN  support  to  operations  in  the  three  roles  that  it  will  be  employed  by  C7F.  The  roles 
are  as  an  embarked  CJTF  with  other  supported  staff(s)  embarked,  as  an  embarked 
JFMCC/NAVFOR,  and  as  the  Fleet  JFN/JFN  supporting  deployed  RTCs  and  RTC  Lites. 

Additional  benefits  of  this  initiative  include  providing  material  to  update  the  JFACC  (Afloat) 
PACAF  CONOPS,  define  personnel  and  training  requirements  for  X-INT  fusion  to  the  Target 
Data  Base,  and  examination  of  JFN  impact  on  the  Air  Tasking  Order  (ATO)  process.  Another 
important  objective  is  to  assess  the  adequacy  of  USS  BLUE  RIDGE’s  legacy  communications  to 
support  JFN. 

All  of  the  stimulus  necessary  to  examine  the  CONOPS/SOP  will  be  by  simulation.  There  are  no 
live  events  during  the  CPX.  During  the  CPX,  JWFC  will  provide  the  majority  of  the  simulation, 
as  they  are  tasked  by  CPF  to  support  the  CPX  primary  goal  of  certifying  C7F  as  a  CJTF.  NWDC 
will  provide  some  UAV  and  cross-INT  simulation  for  direct  stimulation  of  the  JFN  suite  aboard 
USS  BLUE  RIDGE.  The  JWFC  simulation  quality  may  constrain  NWDC’s  ability  to  validate 
the  C7F  JFN  CONOPS.  A  C7F  constraint  is  that  during  the  CPX  all  participants  will  use  legacy 
communications  /  systems  only.  Any  work  not  completed  during  the  CPX  will  continue  into  the 
TT03  FTX  as  required. 

Key  participants  include  the  entire  CJTF  command  structure  and  Component  Commanders. 
JFACC  participation  is  essential  to  meet  the  majority  of  objectives  in  addition  to  supporting 
examination  of  USAF  ISR  Manager  (ISRM)  to  JFN  operations. 

The  following  lists  JFN  equipment  that  was  installed  on  the  Blue  Ridge  and  its  purpose. 


Application 

Purpose 

Gale  Lite 

On  a  TES  MFWS  applied  to  ELINT  analysis. 

TES-N 

Nomination  of  TSTs.  Sensor  management. 

JSIPS-N/PTW 

Georefinement  of  TST  positions 

GCCS-M 

COP,  track  management.  Track  exchange  with  TES-N. 

Ku-band  SATCOM  network 

Support  FBE  network 

MUSE/AFSERS 

Simulated  imagery  and  video  for  Predator,  U-2  and  Global  Hawk 

JSAF 

In  the  CPX,  supported  imagery  generation  for  MUSE/AFSERS. 

In  FTX,  JSAF  was  the  stimulator  for  the  full  exercise. 

JTLS 

CPX  stimulator 

ADOCS 

Cross  Component  TST  collaboration  and  TST  target  management 

IRC/I  WS 

Collaboration 

IPL 

Central  imagery  repository 

Electronic  Target  Folder 

Repository  for  all  TST  data. 

2.2.1  TST  Processes  Initiative  Questions 
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Analytical  questions  that  support  C7F  JFN  CONOPS  /  C7F  TST  SOP  examination  include: 

Question  1 :  How  do  the  limitations  of  the  current  wideband  architecture  (systems  and  networks) 
that  supports  sensor  control,  ISR  fusion,  and  national  imagery  reach  back  aboard  LCC-19  when 
JTF  and  JFACC  (Forward/Afloat)  staffs  are  embarked,  affect  the  functionality/capability 
inherent  to  the  installed  JFN  suite? 

Question  2:  What  contributions  are  made  by  C7F  JFN  CONOPS  and  the  underlying  SOP, 
interfaces,  and  multi-database  infonnation  displays,  to  situational  awareness  of  the  embarked 
(aboard  a  JFN  equipped  LCC)  warfighter  at  the  Operational  level? 

Question  3:  Does  the  C7F  JFN  CONOPS  and  the  underlying  SOP  provide  sufficient  guidance  to 
use  the  additional  JFN  functionality  /capability  to  enable  time  sensitive  targeting  operations? 

Question  4:  Does  the  C7F  JFN  CONOPS  and  the  underlying  SOP  reveal  necessary  changes  to 
systems,  architectures,  and  information  flow  processes  required  to  exploit  the  added  capability  of 
an  afloat  JFN  (supporting  the  JTF  staff  and  a  JFACC  forward)  and  an  ISR-M  supporting  the 
JFACC  Main? 

Question  5:  Does  the  C7F  JFN  CONOPS  and  the  underlying  SOP  support  use  of  JFN 
functionality/capability  aboard  the  LCC  to  affect  the  responsiveness  and  reliability  of  ISR 
command  and  control  with  the  JFACC  (Forward/Afloat)  as  the  coordinating  agency? 


2.3  COALITION  INITIATIVE 

The  second  initiative  focuses  on  the  examination  of  a  distributed,  maritime  sensor  and  fires 
network  that  integrates  a  coalition  engagement  node  within  that  network.  This  network  will  be 
overseen  by  a  Experimental  (XP)  Strike  Warfare  Commander’s  XP  Cell.  This  XP  Commander, 
as  directed  by  the  Joint  Forces  Maritime  Component  Commander  (JFMCC),  will  interact  as  the 
maritime  support  segment  to  the  JTF  TST  operations  during  the  FTX.  This  XP  Cell  will  be 
embarked  aboard  USS  Blue  Ridge.  The  goal  is  to  examine  interface  and  process  requirements 
that  support  maritime  participation  in  JTF  level  TST  operations  in  a  coalition,  distributed 
environment. 

The  initiative  will  exercise  dynamic  management  of  a  tiered,  multi-INT  sensor  architecture 
within  the  experimental  architecture  to  support  both  the  TST  operational  requirements.  NWDC 
will  achieve  this  by  building  on  past  FBE  experimentation  in  ISR  Operations  to  get  the  right 
“ISR  feeds/data/info”  to  allow  an  enhancement  in  the  “fusing”  of  sensor  infonnation  to  support 
the  AP  cell  and  its  assigned  combatants.  This  initiative  will  occur  only  during  the  FTX  phase  of 
TT03. 

NWDC  will  establish  a  Coalition  Fires  C2  grid  interface  with  NFN  through  use  of  a  fires  C2 
tool,  the  Army  Deep  Operations  Coordination  System  (ADOCS).  Temporary  installations  of 
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ADOCS  workstations  in  the  Commander,  Seventh  Fleet’s  Flagship,  USS  Blue  Ridge  and  in  a 
series  of  virtual  combatants  that  will  comprise  the  maritime  engagement  nodes.  These  nodes  are 
the  virtual  DDX  at  Naval  Surface  Warfare  Center  in  Dahlgren,  Virginia,  the  E-2Xv  at  the  Naval 
Warfare  Development  Command  in  Newport,  Rhode  Island,  and  the  virtual  ANZAC  at  the 
Defense  Science  and  Technology  Organization  laboratory  at  Fern  Hill,  Australia. 

By  working  through  the  C7F  Joint  Intelligence  Center  and  the  JFACC  Afloat  TST  cell,  NWDC 
will  examine  the  information  flow  and  other  engagement  processes  that  are  required  in 
establishing  a  coalition  engagement  grid  within  a  larger  coalition  force  structure 

The  addition  of  Global  ISR  Capability  (GISRC)  to  the  maritime  firing  units  provides  future  ISR 
capability  and  will  enable  the  firing  units  to  monitor  simulated  UAV’s  in  a  Call  for  Fire  spotting 
role  and  in  a  strike  support  role. 

Stimulus  will  be  primarily  from  the  NWDC  simulation  federation.  This  federation  and  the 
associated  stimulus  it  provides,  along  with  a  simulated  Mission  Reconfigurable  Unmanned 
Undersea  Vehicle  (MR  UUV)  deployed  from  a  virtual  SSN  at  NUWC,  will  contribute  to  overall 
ISR  stimulation  effort  for  the  FBE. 

An  example  of  the  examined  future  weapons  capability  comes  in  the  form  of  a  virtual  DD(X) 
configured  with  the  Long  Range  Land  Attack  Projectile  (LRLAP),  an  future  ballistic  land  attack 
missile  and  Tactical  Tomahawk  surface  launched  cruise  missile.  Targeted  date  for  potential 
capabilities  is  the  2007-2010  timeframe. 


2.3.1  Coalition  Initiative  Questions 

Analytical  questions  that  support  establishment  and  examination  of  requirements  for  utilization 
of  a  Distributed  Maritime  Sensor  and  Fires  network  that  integrates  a  coalition  engagement  node 
within  that  network  examination  include: 

Question  1 :  What  instances  demonstrate  the  current  security  processes  and  multilevel 
security  technologies  enable  or  inhibit  the  “seamless”  transfer  of  warfighting  information 
between  joint  and  coalition  forces? 

Question  2:  Do  the  current  security  processes  and  technologies  support  distributed 
collaborative  planning  between  joint  and  coalition  forces? 

Question  3:  Does  the  addition  of  a  “dedicated”  level  of  command  and  control  (XP  Cell) 
enhance  or  detract  from  the  ability  of  the  JOA  TST  agent  (JFACC)  to  utilize  JFMCC  assets  in 
the  prosecution  of  a  JTF  level  TST  campaign? 

Question  4:  Does  the  example  in  this  event,  of  a  networked  maritime  engagement 
platform,  produce  a  capability  to  dynamically  command  and  control  non-organic  ISR  and  strike 
assets  in  prosecution  of  a  JTF  level  TST  campaign? 
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3.0  RECONSTRUCTION 


3.1  IMPACTS  ON  THE  EXPERIMENT 

Circumstances  significantly  affected  the  ability  to  obtain  the  desired  data  for  this  Initiative. 

•  A  TST  process  was  not  in  place  at  the  start  of  the  FTX. 

•  The  FBE-K  Fires  events  and  organization  was  almost  entirely  disconnected  operationally 
from  the  Tandem  Thrust  2003  FTX  in  which  Commander  Seventh  Fleet  was  conducting 
live  training  events. 

•  Almost  all  the  personnel  involved  in  the  Fires  Initiative  were  augmentees  new  to  the 
equipment,  TST  process  as  it  was,  and  environment. 

•  There  were  numerous  equipment  and  information  failures. 

The  following  describes  the  impact  of  these  circumstances  on  the  ability  to  meet  initiative 
objectives.  Also  provided  is  a  listing  of  the  daily  TST  events  from  the  MSEL. 

Events  impacting  the  experiment  began  before  it  began.  More  than  a  month  prior  to  FBE-K  the 
proposed  JFN/TST  CONOPS  was  rejected  by  Commander  Seventh  Fleet  and  it  was  decided  to 
use  the  PACAF  TST  SOP  as  a  basis.  This  SOP  is  not  written  for  a  JFACC  Afloat  with  the  CJTF 
so  is  not  entirely  appropriate  for  this  initiative's  objectives.  Conversely,  it  can  also  be  said  that 
the  preparation  for  the  FBE  Fires  initiative  was  not  entirely  appropriate  for 
COMSEVENTHFLT’s  objectives.  The  result  was  that,  rather  than  CONOPS  evaluation  and/or 
validation,  the  experiment  shifted  to  a  focus  on  observing  and  evaluating  activities  in  order  to 
formulate  workable  procedures. 

Part  of  the  FBE-K  Fires  Initiative  involved  an  experimental  Navy  Strike  Warfare  Commander, 
called  Xray  Papa,  to  play  a  key  role  in  TST  under  the  JFMCC.  By  design,  Xray  Papa  would 
have  been  embarked  in  the  aircraft  carrier  with  the  JFMCC,  but  due  to  uncertainty  surrounding 
carrier  deployments  related  to  Operation  Enduring  Freedom  and  Operation  Iraqi  Freedom,  it  was 
infeasible  to  install  the  equipment  necessary  to  set  up  Xray  Papa  aboard  the  carrier.  Therefore 
Xray  Papa  was  embarked  aboard  Blue  Ridge.  The  actual  JFMCC  for  Tandem  Thrust  03  was 
embarked  in  the  carrier  Vinson,  and  was  engaged  in  the  live  exercises  of  the  FTX,  but  not  the 
simulated  Fires  events  of  the  FBE.  For  the  purposes  of  TST  command  and  control  in  ADOCS, 
e-mail,  and  chat,  Xray  Papa  aboard  Blue  Ridge  simulated  being  the  JFMCC. 

Before  the  experiment  it  was  also  learned  that  the  Air  Force  would  not  man  a  JFACC  Afloat  as 
planned,  partly  due  to  policy  and  partly  due  to  demands  of  Operation  Iraqi  Freedom.  A  JFACC 
was  established  at  Hickam  Air  Force  Base  during  the  CPX,  and  was  closed  down  during  the 
FTX.  A  group  of  three  Air  Force  officers  from  Hickam  were  embarked  aboard  Blue  Ridge 
during  the  FTX  to  act  as  a  JFACC  TST  Cell  in  Hickam  would.  There  was  also  an  FTX  live-fly 
cell  set  up  in  the  Joint  Air  Operations  Center  aboard  Blue  Ridge,  but  they  didn’t  participate  in 
the  simulated  FBE  Fires  initiative  events.  For  the  purposes  of  TST  command  and  control  in 
ADOCS,  e-mail,  and  chat,  the  JFACC  TST  Cell  simulated  actions  of  a  larger  JFACC  Air 
Operations  Center  in  addition  to  TST  coordination. 
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The  Expeditionary  Strike  Group  (ESG)  flagship,  USS  Essex  was  outfitted  with  a  JFN  Remote 
Terminal  Capability  (RTC).  However,  neither  the  embarked  ESG  Commander  nor  Special 
Operations  Commander  participated  in  the  FBE  Fires  initiative  events.  For  the  purposes  of  TST 
command  and  control  in  ADOCS,  e-mail,  and  chat,  Xray  Papa  aboard  Blue  Ridge  simulated 
being  the  Joint  Forces  Fand  Component  Commander  (JFFCC)  and  the  Joint  Special  Operations 
Task  Force  Commander. 

The  combination  of  a  lack  of  CONOPS  to  test,  lack  of  connection  between  the  fires  initiative  and 
actual  component  commanders  and  live  events,  artificial  manning  of  essential  command  and 
control  nodes,  limited  participation  actual  Seventh  Fleet  personnel,  limited  training  of 
augmentees  and  equipment  difficulties  resulted  in  limited  data  from  which  conclusions  could  be 
drawn.  Even  so,  data  was  obtained  that  throws  light  on  training  needs  and  on  the  use  of  JFN  for 
TST  by  the  Fleet. 


3.1.1  Manning  Impacts 

Reliance  on  Augmentees:  Almost  all  the  personnel  involved  in  the  Fires  Initiative  were 
augmentees  new  to  the  equipment,  TST  process  as  it  was,  and  environment.  Every  ADOCS 
watchstation  in  the  FTX  was  manned  by  an  augmentee.  The  TST  Targeting  Officer  in  the  JIC 
and  all  but  two  of  the  officers  in  the  Xray  Papa  cell  were  reservists.  Plus  there  were  three  Air 
Force  officers  from  Hickam,  and  two  operators  on  temporary  duty  from  NWDC.  The  training  on 
ADOCS  started  when  they  embarked  aboard  Blue  Ridge  a  few  days  before  the  commencement 
of  the  FTX,  and  the  experience  they  gained  left  with  them  when  they  debarked  the  last  day.  The 
Seventh  Fleet  staff  was  primarily  engaged  in  the  live  exercises  of  the  FTX  as  well  as  monitoring 
real-world  concerns.  The  C7F  Battle  Watch  was  not  involved  in  the  FBE  Fires  events. 

-  Impact:  Much  of  the  FTX  was  a  learning  experience  for  the  augmentees. 

Artificial  Component  Commanders:  All  actual  Tandem  Thrust  FTX  Component  Commanders 
were  engaged  in  live  FTX  exercises  and  not  engaged  in  the  FBE  Fires  initiative.  All 
Component  Commander  roles  for  TST  were  played  by  Xray  Papa  and  JFACC  TST  Cell 
augmentees,  co-located  aboard  Blue  Ridge. 

-  Impact:  The  process  did  not  exercise  realistic  coordination  between  battle  watch  staffs. 
For  example,  realistic  deconfliction  wasn’t  conducted,  and  most  procedural  issues  could  be 
resolved  easily  by  face-to-face  discussion. 


3.1.2  Training  Impacts 

TES-N  Operator  Experience  Fevel:  Although  reported  as  problematic  during  the  CPX,  the  TES- 
N  operators  were  entirely  up  to  the  task  of  using  the  multi-function  workstations  for  the  FTX 
TST  events.  This  was  due  in  part  to  experience  gained  during  the  CPX,  plus  additional  training 
by  the  JFN  Mobile  Training  Team.  But  there  was  another  training  deficiency  that  was  apparent 
during  FTX  when  TES-N  had  a  greater  role  in  a  tactical  sensor-to-shooter  process.  The 
intelligence  specialists  in  the  JIC  are  trained  to  develop  and  produce  intelligence  products  at  the 
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operational  level  of  war.  During  the  FTX,  they  were  put  into  the  unaccustomed  position  of 
tactical  level  evaluation  of  infonnation  and  tasking  of  ISR  assets  in  real  time.  Their  previous 
training  and  experience  didn’t  prepare  them  to  have  the  sense  of  urgency  needed  for  tactical 
operations  for  TSTs. 

-  Impact:  Data  collected  on  the  processing  times  for  information  with  JFN  within  the  Blue  Ridge 
JIC  are  not  likely  to  be  characteristic  of  processing  times  for  operators  trained  and  experienced 
in  tactical  operations. 

Simulation  Limitations:  The  simulation  imagery  had  blurry  gray  background  and  very  distinct, 
clear  black,  clip-art  targets  of  interest.  The  very  distinct  clip-art  targets,  that  were  identical  to 
clipart  in  the  very  concise  “recognition  guide”  trivialized  the  TST  requirement  for  Positive  ID 
(PID)  of  targets,  (i.e.,  whenever  a  distinct  black  spot  was  noticed,  it  was  by  definition  a 
positively  ID’d  target).  Collateral  Damage  Estimates  (CDE)  for  targets  was  trivialized  because 
all  targets  were  clearly  situated  in  wide-open  spaces.  Simulation  imagery  lacked  meta-data 
needed  by  IS  imagery  analysts  for  developing  accurate  aimpoints.  Visual  aimpoint  estimation, 
without  distinct  high-resolution  reference  points,  and  without  sophisticated  machine-aided 
imagery  registration  was  not  useful  for  precision  aimpoints.  Most  images  lacked  precision 
elevation  data.  Lack  of  reality  in  the  simulation  had  a  strong  effect  on  training. 

-  Impact:  Command  and  control  processes  for  geo-refinement  of  precision  aimpoints  and 
mensuration,  which  has  been  a  critical  element  of  previous  FBE  fires  experimentation,  was 
essentially  eliminated  from  FBE-K.  Analysis  using  JFN  for  positive  ID  and  collateral  damage 
estimation,  which  were  critical  elements  of  TST  processes  in  Operation  Iraqi  Freedom,  were  also 
essentially  eliminated. 


3,1.3  Systems  /  Data  Impacts 

ADOCS  ran  poorly  on  existing  computers  on  Blue  Ridge  classified  LAN:  Operators  reported 
that  they  experienced  delays  of  several  minutes  between  mouse  clicks  and  computer  responses. 

-  Impact:  Time-sensitive  actions  could  not  be  accomplished  in  a  timely  manner. 
Procedures  and  training  were  negatively  affected. 

No  Receipt  of  COMINT  In  SCI  TES-N:  C7F  does  not  currently  use  the  SCI  side  of  TES-N  for 
COMINT  analysis. 

-  Impact:  This  meant  that  any  COMINT  injects,  intended  to  be  used  as  part  of  for  cross- 
INT  analysis  by  the  JFN  Team  had  to  be  provided  by  hardcopy  or  e-mail,  and  considered  off¬ 
line. 

TES-N  Interface  with  GCCS-M  Functionally  Limited:  The  TES-N  manual  input  to  GCCS-M 
COP  worked  one  day  during  the  FTX  training,  but  not  for  injecting  any  TST  tracks  during  the 
remainder  of  the  FTX. 

-  Impact:  TST  nominations  were  never  “pushed”  to  the  COP,  important  to  the  “Track” 
step  of  the  TST  process,  to  enhancing  the  commander’s  situational  awareness,  and  to  the 
“context”  in  which  TST  engagement  decision-making  must  take  place. 
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TES-N  Could  Not  Attach  Images  to  TST  Nominations:  The  Target  Nomination  application  in 
TES-N  did  not  provide  for  the  attachment  of  accompanying  images  /  image  “chips”  (a  shortfall 
identified  during  FBE-J  that  was  reportedly  to  be  rectified  by  FBE-K). 

-  Impact:  During  MSEL  Events,  TST-related  images  were  manually  moved  (FTP)  to 
PTW,  with  the  nominating  Analyst  providing  verbal  cueing  to  the  PTW  operator  as  to  which 
Target  Block  Number  related  to  which  image.  The  PTW  analyst  then  changed  the  image 
filename  appropriately  (much  easier  to  do  in  PTW  than  TES-N),  and  saved  the  re-named  image 
to  a  shared  network  drive.  The  JIC  Targeting  Officer  then  drafted  a  SIPRNET  email  (in  MS 
Outlook),  and  attached  the  appropriate  image(s)  from  the  shared  network  drive,  and  sent  the 
email  to  the  NWDC  TST  Target  Folder  Server  for  ingest. 


3,1.4  Equipment  Status  Matrix 

The  following  table  (in  five  segments)  shows  the  daily  status  of  JFN  equipment  during  FTX. 
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DATE 

(Guam 

time) 

COMINT  (via  SI 
beast) 

ELINT  (via  TDDS) 

ELINT  (from  TES-N 
Gale  into  ITD) 

IMINT  (via  JCA) 

FRI  25 
APR 

Trying  to  get  C7F  CTR 
to  script  and  send  via 
SI  beast  back  to 
herself  on  TES-N 

TNMC  will  not  accept 
injects  from  JSAF  or 
ISR  UUV  (workaround 
via  ASSET) 

New  CTT,  needs 
training,  but  first  had 
account  issues 

Used  to  transfer  sim 
"PHOTINT"  from  ISR 
UUV  in  NITF  format. 

SAT  26 
APR 

Still  configuring  SCI 
side  of  TES-N  to  reev 
NRTD  SMTP  feed 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Not  used  in  todays 
Events 

SUN  27 
APR 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Not  used  in  todays 
Events 

MON  28 
APR 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  could  not  be 
displayed  on  ITD 

Successfully  pulled 
from  JCA  to  BLR  IPL, 
used  by  analysts  in 
PTW  and  TES-N 

TUE29 

APR 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Successfully  pulled 
from  JCA  to  BLR  IPL, 
used  by  analysts  in 
PTW  and  TES-N 

WED  30 
APR 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Successful 

THU  01 
MAY 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Not  used  in  todays 
Events 

FRI  02 
MAY 

No  further  progress 
(unable  to  examine 
further) 

Using  ASSET 
workaround  to  send 
LOBs;  not  showing  up 
in  TES-N  GALE 

Non-LOB  ELINT 
coming  to  TES-N 
GALE  being  input  to 
Cross-INT,  displayed 
on  ITD 

Not  used 

22 


DATE 

(Guam 

time) 

U-2  Imagery  (fm 
AFSERS  TENCAP) 

U-2  Telemetry  (fm 
AFSERS  TENCAP) 

Video  (from  AFSERS 
MUSE) 

Images  to  PTW  for 
aimpoint  refinement 

FRI  25 
APR 

Not  explicitly  used  in  todays 
Event,  but  tested  good 

Not  explicitly  used  in 
todays  Event,  but 
tested  good 

Video  rec'd,  chips 
produced,  used  for  target 
noms 

DPPDB  rec'd,  being 
loaded 

SAT  26 
APR 

Not  used  in  todays  Events, 
but  tested  good 

Not  used  in  todays 
Events,  but  tested 
good 

Video  rec'd,  chips 
produced 

DPPDB  loaded,  some 
visual  point  transfer  tests 
conducted 

SUN  27 
APR 

U-2  was  "flying"  but  not 
coming  through  to  TES-N 
EMPS 

U-2  was  "flying"  but  not 
coming  through  to 
TES-N  EMPS 

Video  rec'd,  but  unable  to 
save  chips  to  DBO  (TES-N 
database  problems) 

(Unable  to  examine) 

MON  28 
APR 

"Low  res"  rec'd  in  Screener 
(but  can't  be  chipped),  "hi 
res"  in  DBO  (but  res  still 
poor) 

Telemetry  being  rec'd, 
but  got  EMPS  error, 
"Sensor  not  found." 

Video  rec'd,  chips 
produced,  FTP'd  to  PTW 

Used  DPPDB  to  do 
visual  point  transfer, 
collateral  damage  est., 
etc 

TUE29 

APR 

"Low  res"  rec'd  in  Screener 
(but  can't  be  chipped),  "hi 
res"  in  DBO  (but  res  still 
poor) 

Telemetry  being  rec'd, 
but  got  EMPS  error, 
"Sensor  not  found." 

Video  rec'd,  chips 
produced,  FTP'd  to  PTW 

Used  DPPDB  to  do 
visual  point  transfer, 
collateral  damage  est., 
etc 

WED  30 
APR 

"Low  res"  rec'd  in  Screener 
(but  can't  be  chipped),  "hi 
res"  in  DBO  (but  res  still 
poor) 

Telemetry  being  rec'd, 
but  got  EMPS  error, 
"Sensor  not  found." 

Video  rec'd,  chips 
produced,  FTP'd  to  PTW 
(video  freezes  on  one 
workstation) 

Not  used  in  todays 
Events 

THU  01 
MAY 

Not  used 

not  tried 

Video  rec'd,  chips 
produced,  FTP'd  to  PTW 

Used  DPPDB  to  visually 
estimate  aimpoint 

FRI  02 
MAY 

Not  used 

not  tried 

Video  rec'd,  chips 
produced,  FTP'd  to  PTW 

Sim  National  Image  used 
for  Lat/Long  aimpoint.  No 

elevation 
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DATE 

(Guam 

time) 

Target  nom  to 
ADOCS 

Target  nom  to 
Target  Folder 
Server 

Target  (Manual 
Contact)  to  GCCS- 
M  COP 

GCCS-M  COP  Tracks 
into  TES-N  ITD 

FRI  25 
APR 

Data  integrity  still 
needs  testing. 
Outgoing  queue  inop 
for  one  day  of  OSD 
testing 

[TES-N  unable  to 
attach  images;  work 
around  uses  Outlook, 
PTW,  shared  drive] 

Finally  got  it  to  work  to 
same  level  as  FBE-J 

Has  been  inoperable  for 
several  days  (but  no  one 
noticed) 

SAT  26 
APR 

TST  nom.s 
(ATI.ATRs)  stuck  in 
outgoing  message 
queue 

TST  nom.s 
(ATI.ATRs)  stuck  in 
outgoing  message 
queue 

Not  used  in  todays 
Events,  because  no 
TST  noms  could  be 
done 

Some  tracks  coming  into 
Msg  &  Data  log  again,  but 
not  able  to  examine 
further 

Manual  Contacts 
would  not  save  in 
database,  could  not  be 

SUN  27 
APR 

TST  nom.s  would  not 
save  in  database, 
could  not  be  sent  out 

TST  nom.s  would  not 
save  in  database, 
could  not  be  sent  out 

Tracks  could  not  come  in, 
possibly  due  to  database 
problems 

MON  28 
APR 

TST  nom.s  would  not 
save  in  database, 
could  not  be  sent  out 

TST  nom.s  would  not 
save  in  database, 
could  not  be  sent  out 

Manual  Contacts 
would  not  save  in 
database,  could  not  be 
sent  out 

GCCS-M  tracks  coming 
into  Msg  &  Data  log  again, 
but  could  not  be  pulled  up 
on  ITD 

TUE29 

APR 

TST  nom.s 
successful.  Data 
integrity  needs 
controlled  testing. 

[TES-N  unable  to 
attach  images;  work 
around  uses  Outlook, 
PTW,  shared  drive] 

Attempted,  but  no 
indications  of  success 

Successfully  pulled  up 
tracks  on  ITD,  but  with  no 
labeling 

WED  30 
APR 

Data  integrity  tested. 
Evidence  points  to 
ADOCS  as  culprit. 

Data  integrity  tested. 
ATI.ATR  messages 
unaltered  in  Target 
Folders 

No  indications  of 

success 

Successfully  pulled  up 
tracks  on  ITD,  but  with  no 
labeling 

THU  01 
MAY 

Successful 

[TES-N  unable  to 
attach  images;  work 
around  uses  Outlook, 
PTW,  shared  drive] 

Attempted,  but  no 
indications  of  success 

Successfully  pulled  up 
tracks  on  ITD,  but  with  no 
labeling 

FRI  02 
MAY 

Successful 

[TES-N  unable  to 
attach  images;  work 
around  uses  Outlook, 
PTW,  shared  drive] 

Attempted,  but  no 
indications  of  success 

Successfully  pulled  up 
tracks  on  ITD,  but  with  no 
labeling 
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DATE 

(Guam 

time) 

DIOP  to  ISRM 
(CPX),  ESSEX  RTC 
(FTX) 

File  Xfer  to  ISRM 
(CPX),  RTC /RTC 
Lites  (FTX) 

U-2  Msn  Plan  (to 
AFSERS  TENCAP) 

Cross-INT  replication 
fm  TES-N  to  ISRM  / 
RTC 

FRI  25 
APR 

Told  by  FSRs  that  sim 
data  from  AFSERS 
cannot  be  DIOP'd  (to 
ESSEX  RTC) 

Successful  to  ESSEX 
RTC;  no  exercise 
data  to  DDX  and 
vSSN  RTC  Lites 

ISC  Hutton  (PEO  IWS 
MTT)  updated  Doc's 
original  plan 

Not  attempted 

SAT  26 
APR 

Tape  of  live  SYERS 
mission  "played"  in 
TES-N,  DIOP'd  to 
ESSEX 

Successful  to  ESSEX 
RTC;  no  exercise 
data  to  DDX  and 
vSSN  RTC  Lites 

Plan  updated  by  ISC 
Hutton  successfully 
ingested,  used 

ESSEX  RTC  reportedly 
"pulling"  data  fm  TES-N's 
Cross-INT  database 

SUN  27 
APR 

DIOP'ing  tape  to 
ESSEX  may  have 
contributed  to  TES-N 
non-receipt  of  sim  U-2 

Successful  to  ESSEX 
RTC;  no  exercise 
data  to  DDX  and 
vSSN  RTC  Lites 

Same  plan  used 

ESSEX  RTC  "pulling" 
poss  contributed  to  TES- 
N  database  crash 

MON  28 
APR 

Cut  ESSEX  transfers 
way  back  (not  much  to 
transfer  due  to  dbase 
prob.s) 

Cut  ESSEX  transfers 
way  back;  DDX 
beginning  to  receive 

Same  plan  used,  but 
telemetry  not  feeding 
TES-N  (EMPS  could 
not  "find"  sensor) 

Could  not  replicate 
anything  due  to  corrupted 
files  in  Cross-INT  filter/ 
databases 

TUE29 

APR 

Not  attempted 

DDX  RTC  Lite 
receiving  all  exercise 
data;  not  so  vSSN 

Same  plan  used,  but 
telemetry  not  feeding 
TES-N  (EMPS  could 
not  "find"  sensor) 

Not  attempted 

WED  30 
APR 

Not  attempted 

DDX  and  NUWC  RTC 
Lites  both  rec'ving 
exercise  data. 

Tried  ad  hoc  tasking, 
but  telemetry  still  not 
feeding  TES-N 

Not  attempted 

THU  01 
MAY 

All  Essex  RTC 
operators  aboard  Blue 
Ridge 

not  pushed  today 

not  tried 

Not  attempted 

FRI  02 
MAY 

All  Essex  RTC 
operators  aboard  Blue 
Ridge 

not  pushed  today 

Not  attempted 

Not  attempted 
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3.2  EXPERIMENT  PLANNED  EVENTS 


The  following  are  sanitized  extractions  from  the  Master  Scenario  Event  List.  These  events  were 
designed  to  provide  stimulation  to  Joint  Fires  Network  (JFN)  analysts  and  operators.  The  events 
were  designed  to  start  slowly  and  build  in  complexity  to  help  "players"  gradually  learn  and 
understand  the  analytical  processes  and  infonnation  flows  required  to  use  JFN  to  support  Joint 
Task  Force  (JTF)  level  operations  such  as  Time  Sensitive  Targeting  (TST).  The  events  are 
designed  to  stimulate  the  JFN  operators  to  perform  the  following  operations: 

Find  and  Fix  -  cross-int  analysis  to  detect,  precisely  locate,  and  positively  identify  TSTs; 
Track  -  enter  the  TSTs  into  the  Common  Operating  Picture  (COP); 

Target  -  derive  aimpoint  coordinates  and  nominate  the  TST  for  engagement; 

Engage  and  Assess  -  monitor  the  engagement,  and  conduct  preliminary  Bomb  Hit 
Assessment  /  Battle  Damage  Assessment  (BFJA/BDA); 

Re-Task  -  support  ISR  collection  plan  adjustment  during  execution; 

Re-Engage  -  support  re-engagement  of  TST  as  required. 

These  objectives  were  gradually  introduced,  with  an  initial  schedule: 

25-27  Apr:  Objectives  1-3  only  [Find  &  Fix,  Track,  Target]. 

28,  29  Apr:  Objectives  1-4  [add  Engage  &  Assess]. 

30  Apr  -  2  May:  Objectives  1-6  [add  Re-Task  and  Re-Engage]. 

The  events  are  laid  out  by  day,  with:  Event  number;  target(s)  and  general  location;  event  start 
time;  ISR  data  types/sources.  A  synopsis  of  the  intent  of  each  event  is  provided,  as  well  as 
"Smart  Notes"  (where  needed)  to  indicate  specific  details  needed  for  the  conduct  of  that  event. 
The  following  are  the  planned  events  by  day.  The  next  subsection  will  describe  differences 
between  planned  and  executed  events.  All  are  Guam  days. 

25  APR  -  objectives  1-3  [Find,  Fix,  Track,  &  Target] 

Event  FBE  FIRES  25-1:  Surfaced  sub  activity 

ISR  UUV  COMINT 
ISR  UUV  ELINT/ESM 
ISR  UUV  EO  IMINT. 

SYNOPSIS:  ISR  UUV  on  station;  SIGINT/IMINT  cross-correlation.  Goal  is  to  have  TES-N 
operators  cross-correlate  ISR  UUV-derived  COMINT,  ELINT  and  IMINT/PHOTINT  to 
determine  sub  is  underway,  and  then  pass  that  as  track  data  over  to  COP  for  GCCS-M 
correlation  with  E2-C  derived  surface  track/link  data. 

Event  FBE  FIRES  25-2:  Artillery  battery  on  Tinian 

COMINT 

ELINT 

EO  UAV  video 

SYNOPSIS:  continue  polishing  Find,  Fix,  Track  and  Target  procedures,  this  time  requiring 
multiple  aimpoints  to  cover  the  multiple  targets. 

26  APR  -  objectives  1-3  [Find,  Fix,  Track,  &  Target] 
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Event  FBE  FIRES  26-1:  Ground  artillery  units  on  Tinian 

COMINT 
UAV  EO  video 
U-2  SAR  imagery 

SYNOPSIS:  to  run  through  basic  flow  for  Find,  Fix,  Track,  and  Target  steps,  adding  in  U-2 
retasking. 

Event  FBE  FIRES  26-2:  CDCM  Decoy  on  Tinian 

COMINT 
ISR  UUV 

vSUB  ELINT/ESM 
EO  UAV  video 
EO  U-2  still  imagery 
SYNOPSIS:  vSUB  and  ISR  UUV. 

27  APR  -  objectives  1-3  [Find,  Fix,  Track,  &  Target] 

Event  FBE  FIRES  27-1:  Ground  force  C2  node  near  Tinian  airfield 

COMINT 

open  source/HUMINT 
EO  U-2  still  imagery 
EO  UAV  video 

SYNOPSIS:  continue  polishing  procedures,  adding  in  open  source/HUMINT  reporting  to  the 
mix. 

Event  FBE  FIRES  27-2:  Artillery  battery  on  Tinian 

ISR  UUV  COMINT 
ESM 

EO  UAV  video 

SAR  still  imagery  using  JCA 

SYNOPSIS:  continue  polishing  procedures,  this  time  using  UUV  as  COMINT/ESM  source,  and 
JCA  for  receipt  of  still  SAR  imagery  of  target  area  to  verify  object  locations  seen  in  video,  etc. 

Event  FBE  FIRES  27-3:  UUV  Counter-detection 

SYNOPSIS:  ISR  UUV  detects  threat  emitter  (ASW  aircraft  radar),  requiring  it  to  go  "sinker”. 

28  APR  -  objectives  1-4  [add  Engage  &  Assess] 

Event  FBE  FIRES  28-1:  SA-6  on  Saipan 

COMINT 

ELINT  several  radars 
UAV  EO  video 

SYNOPSIS:  same  as  previous  events  in  the  Find,  Fix,  Track,  and  Target  steps,  but  adding 
Engagement,  and  Assessment  (initial  BHA/BDA). 

Event  FBE  FIRES  28-2:  CDCM  on  Saipan 

ELINT  of  coastal  surveillance  radar 
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HUMINT/SOF 
U-2  EO  imagery 

SYNOPSIS:  UUV  ESM/ELINT  tipper.  SOF  confirm  activity,  think  it  may  be  a  decoy,  but  can't 
tell  due  to  revetments  and/or  stand-off  range.  No  UAV  available  due  to  maintenance.  EMPS 
operator  will  need  to  dynamically  re-task  U-2  to  get  rapid  "overhead"  imagery. 

29  APR  -  objectives  1-4  [add  Engage  &  Assess] 

Event  29-1:  SA-15  on  Saipan 

ELINT  (three  transmissions  from  three  locations  —  "looks"  and  moves) 

P-3  AIP  EO  video 

SYNOPSIS:  Making  "tracking"  element  more  complex  by  trying  to  follow  mobile  SAM's.  Also 
introducing  complication  of  C2  of  multi-mission  (ISR  and  others)-capable  platforms  such  as  P-3 
AIP.  P-3  AIP  gets  "lit  up"  and  shot  at  by  SA-15  but  is  out  of  range,  so  missile  misses;  SA-15  is 
engaged;  P-3  AIP  video  enables  BHA/BDA  by  JFN  operator. 

SMART  NOTES:  P-3(AIP)  must  be  tasked  in  ATO  for  ASW  or  MARPAT  near  SAIPAN  with 
track/orb  it/operating  area  just  out  of  SA-15  max  range 

Event  29-2a:  CDCM  on  Saipan 

UUV  ESM 
ELINT 

UUV  COMINT/ESM 
UUV  IMINT/PHOTINT 
UAV  EO  video 

and  Event  29-2b:  a  different  CDCM  on  Saipan 

UUV  COMINT  btwn  HQ  and  CDCM  unit 
UAV  EO  video 

SYNOPSIS:  conduct  two  TST  events  SIMULTANEOUSLY.  Analysts  will  have  to  recognize 
multiple  targets  exist;  ISR  Ops  will  need  to  adjudicate  use  of  video  sensor  to  PID  and  conduct 
BHA/BDA. 

SMART  NOTES: 

(1)  COMINT  should  indicate  same  HQ,  but  two  different  and  widely-separated  firing 
units; 

(2)  Involves  only  one  radar  site,  supporting  both  firing  units; 

(3)  BHA  should  show  initial  engagement  missed  one  of  the  tiring  units. 

(4)  Geometries  of  target  locations  (i.e.,  CDCM  firing  unit  sites),  radar  location,  and  UUV 
operating  box  must  be  carefully  considered. 

30  APR  -  objectives  1-6  [add  Re-Task  and  Re-Engage] 

Event  30-1:  SCUD  on  FDM 

COMINT  between  HQ  and  SCUD  battery 

EO  video 

U-2  SAR  imagery 

SYNOPSIS:  Re-task  of  U-2  due  to  weather  (similar  to  Event  26-1),  with  engagement  and 
BHA/BDA  added. 

SMART  NOTES: 
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(1)  WEATHER:  EO  video  must  show  fog/obscuration 

(2)  U-2(SAR)  must  be  in  JTF  collection  plan,  putting  aircraft  within  sensor  range,  but  not 
yet  tasked  to  collect  against  that  site 

(3)  U-2  mission  plan/collection  plan  must  be  built  and  loaded  into  EMPS 

Event  30-2:  SCUD  on  Saipan 

COMINT  between  HQ  and  SCUD  battery 
EO  video  (obscured  by  clouds/ground  fog) 

U-2  SAR  imagery 

SYNOPSIS:  Another  U-2  re -task  due  to  weather  (similar  to  Event  30-1),  with  re-engagement 
added. 

SMART  NOTES: 

(1)  WEATHER:  EO  video  must  show  fog/obscuration 

(2)  U-2(SAR)  must  be  in  JTF  collection  plan,  putting  aircraft  within  sensor  range,  but  not 
yet  tasked  to  collect  against  that  site 

(3)  U-2  mission  plan/collection  plan  must  be  built  and  loaded  into  EMPS 

(4)  Need  COMINT  "BDA"  inject 

(5)  Need  U-2(SAR)  image  of  "crater"  with  TEL  a  few  hundred  yards  away 

Event  FBE  FIRES  30-3:  Off-board  threat  detection 

SYNOPSIS:  threat  emitter  (e.g.,  ASW  aircraft  radar?)  detected  off-board  of  ISR  UUV,  requiring 
signal  to  ISR  UUV  for  it  to  go  "sinker". 

1  MAY  -  objectives  1-6  [add  Re-Task  and  Re-Engage] 

Event  1-1:  Ground  force  C2  node  on  Saipan 

COMINT 

ELINT 

JCA  U-2(EO)  still  imagery 
UAV  EO  video 

SYNOPSIS:  presence  of  multiple  vehicles  and  antennae  will  require  multiple  aimpoints.  JCA 
U-2(EO)  imagery  will  assist.  Weather  requires  UAV  also. 

Event  1-2:  SA-6  on  FDM 

ELINT 

UAV  EO  video 
U-2(EO)  still  imagery 
and  Event  1-3:  SCUD  on  FDM 

COMINT  between  HQ  and  SCUD  battery 
UAV  EO  video 
U-2(EO)  imagery 

SYNOPSIS:  Simultaneous  pop-up  of  two  targets.  SA-6  will  complicate  engagement  matters 
(e.g.,  precludes  shooting  SCUD  with  TACAIR  until  it  is  rendered  in-op).  Weather  cleared. 

2  MAY  -  objectives  1-6  [add  Re-Task  and  Re-Engage] 
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Event  2-1:  SCUD  on  FDM 

COMINT  between  HQ  and  SCUD  battery 
EO  video 

U-2(SAR)  imagery 

SYNOPSIS:  (re-run  of  Event  30-1)  Re-task  of  U-2  due  to  weather.  Note  SA-6  on  FDM  (in  Event 
2-4)  will  complicate  situation. 

SMART  NOTES: 

(1)  WEATHER:  EO  video  must  show  fog/obscuration 

(2)  U-2(SAR)  must  be  in  JTF  collection  plan,  putting  aircraft  within  sensor  range,  but  not 
yet  tasked  to  collect  against  that  site 

(3)  U-2  mission  plan/collection  plan  must  be  built  and  loaded  into  EMPS 

Event  2-2:  SCUD  on  Saipan 

COMINT  between  HQ  and  SCUD  battery 
EO  video  (obscured  by  clouds/ground  fog) 

U-2(SAR)  imagery 

SYNOPSIS:  (re-run  of  Event  30-2).  Another  U-2  re-task  due  to  weather  (similar  to  Event  1-1), 
with  re-engagement  added. 

SMART  NOTES: 

(1)  WEATHER:  EO  video  must  show  fog/obscuration 

(2)  U-2(SAR)  must  be  in  JTF  collection  plan,  putting  aircraft  within  sensor  range,  but  not 
yet  tasked  to  collect  against  that  site 

(3)  U-2  mission  plan/collection  plan  must  be  built  and  loaded  into  EMPS 

(4)  Need  COMINT  "BDA"  inject 

(5)  Need  U-2(SAR)  image  of  "crater"  with  TEL  a  few  hundred  yards  away 

Event  2-3:  Ground  force  C2  node  on  Saipan 

COMINT 
ELINT 
EO  video 
JCA  EO  imagery 

SYNOPSIS:  Re-run  of  Event  1-1,  with  adjustments  to  make  sense  in  context  of  other 
simultaneous  Events  of  this  day. 

Event  2-4:  SA-6  on  FDM 

ELINT 

UAV  EO  video 
U-2(SAR)  still  imagery 

SYNOPSIS:  Re-run  of  Event  1-2,  but  this  time  with  same  weather  obscuration  as  in  Event  2-1, 
requiring  U-2(SAR)  imagery  for  PID  and  targeting  quality  imagery. 

SMART  NOTES: 

(1)  WEATHER:  EO  video  must  show  fog/obscuration 
(2)  U-2(SAR)  must  be  in  JTF  collection  plan,  putting  aircraft  within  sensor  range,  but  not  yet 
tasked  to  collect  against  that  site 
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3.2.1  Modifications  to  Planned  Events 


During  the  experiment,  there  were  modifications  in  event  details  and  also  wholesale 
modifications  to  accommodate  to  operator  training  and  expertise.  The  following  lists  those 
modifications. 

4/25  The  day  was  devoted  to  training  augmentees  aboard  Blue  Ridge,  including  reservists  and 
temporary  duty  personnel  on  ADOCS. 

4/26  Event  26-1  did  not  occur  due  to  problems  with  simulation  feeds.  Participants  engaged  in 
process  discussions  about  how  to  use  ADOCS.  Event  26-2  feeds  into  JFN  occurred  as  planned. 
TST  processing  was  hindered  by  internal  communications  difficulties. 

4/27  Event  feeds  into  JFN  occurred  as  planned.  Target  nominations  could  not  be  made  from 
TES-N  due  to  problems  with  TES-N  database.  Nominations  were  manually  entered  from  JIC 
ADOCS. 

4/28  Events  were  not  conducted  due  to  continued  problems  with  TES-N  database.  Fires 
participants  conducted  meetings  to  develop/refine  TST-ADOCS  procedures.  Major  focus  was 
on  defining  color-coding  conventions  for  ADOCS  TST  and  Fires  Managers. 

4/29  -  5/02  Events  run  as  planned. 

3.3  DAILY  CONTEXT  SUMMARY 

The  following  are  summaries  of  the  important  context  for  each  day.  This  context  frames  each 
day's  events  and  provides  some  insight  into  cause-and-effect  for  that  day's  results. 

4/26  Due  to  all  the  impacts  on  the  experiment  described  above,  TST  processes  did  not  go 
smoothly  during  the  first  FBE  exercise  day  from  0700-1500  local.  However,  the  difficulties  and 
the  co-location  of  most  of  the  players  aboard  Blue  Ridge  prompted  a  very  productive  wrap-up 
meeting  in  which  important  insights  arose. 

A  simple  question  from  one  of  the  participants  evolved  into  a  very  productive  discussion 
about  TST  process.  Up  until  this  discussion,  the  people  with  previous  experience  FBE  Fires, 
JFN,  and  ADOCS  experience  couldn’t  prescribe  TST  processes  that  hadn’t  been  approved  by 
C7F.  Instead,  much  was  being  left  for  the  augmentees  to  discover  and  define  a  process  that  (in 
theory)  would  work  aboart  the  C7F  flagship.  That  wasn’t  happening.  Hardware  and  software 
weren’t  functioning  as  intended  and  all  the  FTX  augmentees  really  didn’t  know  enough  to  figure 
out  what  it  was  they  were  supposed  to  do. 

Furthermore,  when  one  of  the  people  with  previous  FBE  Fires  experience  sketched  a 
block  diagram  on  a  whiteboard  to  try  to  clarify  the  ADOCS  processes,  everyone  nodded  except 
the  C7F  Fires  lead.  Basically  he  said  that  the  process  and  roles  of  JFMCC  and  JFACC  as 
sketched  were  not  what  C7F  wanted.  The  fundamental  issue,  that  hadn’t  been  well  understood, 
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and  was  the  reason  that  there  wasn’t  an  approved  CONOPS  going  into  the  FBE,  was  that  as  a 
Joint  Task  Force  Commander,  C7F  wanted  to  use  his  supporting  Joint  Forces  Air  Component 
Commander  to  be  in  charge  of  TSTs.  C7F  did  not  want  his  physical  location  afloat  to  dictate  a 
JFMCC-centric  TST  process. 

During  the  next  hour,  an  executable  process  emerged  that  had  the  concurrence  of  C7F, 
the  JFACC  TST  personnel  and  the  Navy  people  in  the  Xray  Papa  cell.  A  contentious  change  to 
the  pre-planning  for  FBE  Fires  was  that  all  Navy  Strike  aircraft  (all  of  which  were  simulated  FA- 
1 8s)  and  their  airborne  command  and  control  post,  the  virtual  experimental  E-2  were  apportioned 
to  the  JFACC  —  leaving  the  Navy  Strike  Warfare  Commander,  Xray  Papa  with  no  Strike  aircraft. 
The  only  FBE-K  Strike  assets  that  Xray  Papa  (on  behalf  of  the  JFMCC)  still  owned  were  the 
vDDX  and  the  vAnzac. 

4/27  TES-N  problems  plagued  events.  Both  JFN  MSELs  were  executed,  but  TES-N  couldn’t 
make  nominations,  couldn’t  pass  targets  to  GCCS-M,  and  couldn’t  chip  images  to  PTW  which 
would  have  enabled  the  operators  in  the  JIC  to  save  images  to  a  local  hard-drive  for  e-mail 
dissemination.  With  can-do  spirit  the  JIC  people  did  work-arounds  and  manually  nominated 
targets  thru  their  ADOCS. 

ADOCS  operators  reported  that  ADOCS  was  almost  fatally  slow  between  when  the 
operator  clicked  the  mouse  and  when  the  computer  responded.  Delays  were  on  the  order  of  2-4 
minutes.  This  apparently  had  to  do  with  the  ADOCS  being  run  on  the  ship’s  existing  Secret 
LAN  on  existing  PCs. 

Another  process  evolution  occurred  this  day  during  the  end-of-day  post-mortem 
concerning  “Collection  Management.”  It  had  been  assumed  that  the  CJTF  Collection  Manager 
was  in  the  JIC,  but  the  consensus  was  to  push  CM  back  to  JFACC  (“back”  in  the  sense  that  it 
would  go  to  JFACC  Rear  if  they  were  there).  For  FTX,  it  would  actually  be  done  by  one  of  the 
Air  Force  officers  in  the  JFACC  TST  cell  in  Blue  Ridge,  pretending  he  is  the  Collection 
Manager  in  the  JFACC  AOC. 

4/28  TES-N  problems  continued.  TES-N  still  couldn’t  make  nominations  or  pass  targets  to 
GCCS-M.  The  ability  to  chip  images  to  PTW  for  saving  on  a  shared-drive  was  restored.  The 
JIC  continued  to  manually  nominate  targets  in  ADOCS,  and  they  instituted  an  “exercise- 
exercise-exercise”  intelligence  report  to  disseminate  via  e-mail.  TST  process  development 
focused  on  standardization  and  common  understanding  of  ADOCS  block  color-coding. 

4/29  Systems,  TES-N  and  ADOCS,  worked.  Target  nominations  were  made  from  TES-N. 

The  TST  process  flowed. 

Undisciplined  Chat  usage  for  UAV  coordination  lead  to  two  UAVs  being  sent  to  the 
same  point  to  look  for  the  same  target  at  one  time  (instance  of  the  need  for  tactical  Chat 
procedures). 

4/30  The  ADOCS-based  TST  command  and  control  procedures  worked  out  since  the  start  of 
FTX  were  working  smoothly  this  date.  People  had  a  pretty  good  common  understanding  of  what 
color  blocks  meant  what,  and  who  was  responsible  for  various  actions. 

5/01  The  exercise  day  was  delayed  in  JIC  due  to  problems  with  the  ship’s  Secret  LAN. 
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Accordingly,  there  was  no  ADOCS,  no  chat,  no  SIPRNET  e-mail,  etc.  until  problems  were 
resolved. 

5/02  Mostly  routine  MSEL  injects  and  processing.  One  particular  sequence  was  noteworthy: 
Background:  Two  SCUD  TELs  (with  stowed  missiles)  were  found  with  TES-N,  nominated  into 
ADOCS,  and  processed  for  engagement.  An  engagement  was  conducted  and  BHA  requested. 
There  was  no  indication  of  hits  anywhere  near  the  target.  Everything  was  pretty  routine  up  to 
here,  then  got  interesting.  The  UAV  then  saw  the  TELs  relocate  a  very  short  distance  and  erect 
their  missiles  for  launch.  The  command  and  control  processing  then  became  confused.  The 
immediate  choices  available  were  to  consider  the  TELs  in  their  new  position  erected  for  launch 
as  new  TSTs,  or  consider  them  re-strikes  of  targets  already  on  the  Joint  TST  list.  Superficially, 
this  can  be  considered  as  merely  a  TTP  or  SOP  issue.  But  either  choice  has  some  disadvantages. 
This  points  to  some  issues  about  how  ADOCS  functions,  and  suggests  some  other  functionality 
is  needed  for  the  prosecution  of  TSTs  using  ADOCS.  This  is  discussed  further  in  the  following 
section  on  consequences. 

Coalition  Daily  Context: 

4/27  ADOCS  tenninals  in  JFMCC/XP  cell  were  attached  to  the  network  at  10  Mb/s.  This 
resulted  in  very  slow  performance  which  was  compounded  by  operators  repeating  keyboard  and 
mouse  functions  since  there  was  no  visual  feedback  similar  to  a  MS  Windows  hourglass  symbol 
indicating  that  the  computer  had  accepted  the  command. 

ADOCS  times  were  one  hour  behind  Guam  time  due  to  network  program  overriding  local 
computer  time  and  automatically  setting  ADOCS  clocks  to  Yokuska  time. 

GCCS-M  was  displaying  multiple  tracks  due  to  a  problem  with  real  world  nodes  not 
properly  using  full  UIDs  in  processing  of  tracks  (thus  having  no  way  to  correlate  the  same  track 
reported  from  multiple  sources. 

4/28  ADOCS  time  problem  continued  and  was  not  corrected  for  the  rest  of  the  experiment. 

4/29  There  were  occasional  ADOCS  server  lockups.  The  ADOCS  remarks  field  for  each  target 
was  of  limited  size,  and  not  enough  information  could  be  passed  about  the  target  in  some  cases. 

5/1  Target  Weapon  Pairing  (TWP)  is  not  working  correctly.  An  operator  would  bring  up  a 
weapon  list  for  a  target,  and  the  availability  time  of  the  weapon  would  not  always  overlap  with 
the  time  window  of  the  target.  The  explanation  we  received  from  ADOCS  techs  was  that  there 
was  no  JMIMS  data  as  there  would  be  in  an  operational  environment. 


3.4  SUMMARY  CONTEXT  CONSEQUENCES: 

The  main  impact  created  by  the  above  noted  difficulties,  with  regard  to  meeting  this  initiative's 
objectives,  was  that  JFN  was  operated  in  an  artificial  environment.  Procedures  were  not  what  is 
or  will  be  used  for  TST,  hence  evaluation  of  these  procedures  to  determine  JFN's  contribution 
will  have  marginal  validity.  The  experiment  was  decoupled  from  the  exercise. 
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Many  critical  elements  of  the  TST  process  were  artificial: 

Cross  component  coordination  and  deconfliction 
Inter-platform  communications 
Positive  ID 

Collateral  Damage  Estimate 
Aimpoint  Geo-refinement 
Collection  Management 

TES-N  operator  training  conducted  during  the  CPX  leading  up  to  the  FTX  was  apparently 
successful  in  getting  the  JIC  imagery  analysts  comfortable  and  competent  at  their  multi-function 
workstations. 


35 


4.0  ANALYSIS  APPROACH 


Here  we  describe 

•  decomposition  of  the  two  initiatives  that  make  up  the  Fires  portion  of  FBE-Kilo, 

•  C2  structure  tested, 

•  analysis  methodology,  data,  and  tools,  and 

•  CONOPS  and  TTP. 

This  fonns  the  basis  for  understanding  the  data  and  processes  used  to  reach  the  Report's 
conclusions.  Actually,  for  the  reason  stated  in  the  next  paragraph  and  reasons  found  in  the  body 
of  this  report,  this  section  contains  only  a  rudimentary  description  of  what  was  to  be  done  from 
the  experiment. 

The  reader  will  note  that  this  section  is  somewhat  skimpy.  This  is  because  there  is  little  data  to 
analyze  from  this  experiment.  Rather  than  analyze  data  and  information  to  produce  quantitative 
and  qualitative  results  about  processes  and  systems,  the  analysis  has  reverted  mainly  to 
identifying  what  went  wrong  and  recommendations  for  future  improvements. 


4.1  INITIATIVES  DECOMPOSITION 

Basic  initiatives  decomposition  is  given  by  the  questions  presented  earlier.  Here  we  further 
decompose  by  correlating  questions  with  the  data  needed  to  address  them. 

4.1.1  TST  Processes  Initiative  Decomposition 

Four  questions  have  been  presented  above  for  this  initiative.  The  first  deals  with: 

•  how  the  particular  FTX  architecture  affects  the  functioning  of  the  JFN  suite. 

The  next  four  questions  deal  with  TST  CONOPS  or  SOP  with  regard  to: 

•  CONOPS/SOP  adequacy. 

•  Interaction  between  CONOPS/SOP  and  systems. 

In  order  to  address  these  issues,  it  is  necessary  to  determine  how  well  the  various  sub-processes 
within  TST  are  functioning  and  what  support  is  being  provided  by  JFN  to  carry  out  those 
processes.  It  is  further  necessary  to  determine  how  the  processes  are  addressed  in  pertinent 
CONOPS  and  SOPs. 

The  decomposition  needed  is  to  break  down  the  TST  process  into  identifiable  processes.  The 


initial  breakdown  is: 

• 

Find 

• 

Fix 

• 

Track 

• 

Target 

• 

Engage 

• 

Assess 
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Further  breakdown  that  shows  sub-processes  and  the  organizations/people  that  perform  them  is 
required.  This  is  done  for  a  complete,  fully  functional,  JFN  suite  in  Appendix  E.  It  is  done  for 
the  particular  configuration  that  was  used  for  FTX  in  the  following  Section  4.2. 


4.1.2  Coalition  Initiative  Decomposition 

Rather  than  decompose  the  Coalition  Initiative,  its  relationship  to  data  is  best  expressed  by  a 
simple  question: 

Are  the  information  presented  in  the  U.S.  COP  and  the  Coalition  COP  the  same? 

The  data  needed  for  this  evaluation  is  track  information  on  either  side  of  the  Radiant  Mercury 
filter. 


4.2  EXERCISE  TST  STRUCTURE 


The  TST  process  is  outlined  in  the  Experiment  Plan  with  the  following  PACAF  SOP  figure: 


It  was  planned  to  support  the  TST  process  with  the  following  distribution  of  functions  and 
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supporting  systems,  (figures  from  the  Experiment  Plan). 


FOTC 

Operator 

GCCS-M 

BLR  JOCC 


XP  (Maritime 
Strike) 
ADOCS 


Sr  tntel 
Duty  Off 
TES-N 


ISR 

Manager 

TES-N 


BLR  JAOC 


4.2.1  Experiment  TST  Structure  Executed 

The  above  diagrams  show  the  structure  for  the  LTX  exercise.  Due  to  the  various  difficulties 
noted  earlier  in  this  report,  the  structure  for  the  LBE-K  experiment  was  not  the  same.  The 
following  shows  the  organizations,  functions,  and  supporting  systems  actually  used. 


ELINT 

Analyst 

TES-N 
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Imagery 
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TES-N 
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Collection 
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Targeting 
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ADOCS 


The  p 
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Attack 
Ops  Officer 
ADOCS 


TCT 

Team  Chief 
ADOCS 


TST 

Technician 

ADOCS 


BLR  JOCC  S  BLR  JAOC  IJLACC  TST  Cell) 


ISR 

Manager 

TES-N 


tartly 

.directly 


with  the  Video  Analyst  and  with  Sensor  Controllers.  This  bypassed  the  ISR  Sensor  Manager 
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much  of  the  time.  The  ISR  Manager  attempted  to  coordinate  with  the  JIC  Collection  Manager, 
but  through  e-mail  and  Chat.  In  order  to  have  a  more  streamlined  process,  it  was  arranged  to 
have  the  Video  Analyst  communicate  directly  with  the  Sensor  Controller. 

The  XP  Cell  played  an  active  role,  but  with  a  large  degree  of  artificiality.  People  played  the 
roles  of  JFMCC,  JFLCC,  etc.,  in  order  to  have  their  staff  input  represented.  There  was  no  real 
JFMCC  coordination  (recall  that  this  was  the  experiment,  not  the  exercise).  XP  interactions  with 
the  JAOC  was  largely  work-arounds  to  have  a  functioning  process  for  the  experiment,  not  to 
represent  realistically  real-world  operations. 


4.3  ANALYSIS  METHODOLOGY,  DATA,  AND  TOOLS 

Former  FBE  Fires  initiatives  have  placed  most  of  their  emphasis  on  the  TST  timeline.  How 
rapidly  the  detect-to-engage  cycle  could  be  performed  was  of  primary  interest.  That  is  not  the 
case  in  this  experiment,  so  timelines  will  receive  only  cursory  attention.  As  noted  above,  interest 
her  is  on  how  well  sub-processes,  or  tasks,  can  be  perfonned. 

Task  performance  assessment  is  normally  done  in  four  ways: 

•  Participant  surveys. 

•  Expert  observers  monitoring  nodes  in  the  process. 

•  Determination  of  task  performance  times. 

•  Determination  of  task  perfonnance  capacities. 

The  first  two  are  subjective  and  the  last  two  are  quantitative,  providing  statistics,  best 
performance,  and  correlations  between  situation  and  performance  (case  studies). 

Because  of  the  various  difficulties  encountered  in  FBE-K,  the  last  two  assessment  methods  could 
not  provide  useful  results.  Times  and  capacities  were  strongly  influenced  by  the  need  to  develop 
and  use  work-arounds.  Thus,  results  produced  would  be  indicative  of  processes  that  had  little  to 
do  with  the  initiative.  An  even  greater  difficulty  is  that  processes  and  tasks  were  often 
interrupted  by  equipment  failures  or  the  need  to  compensate  on-the-fly  for  missing  information. 

The  survey  tools  used  are  presented  in  Appendix  F.  Summaries  and  interpretation  of  survey 
results  are  in  the  Results  section. 


4.4  DATA  STRUCTURE 

The  table  below  outlines  the  essential  TST  event  data  that  ideally  should  have  been  collected 
from  the  various  Fires  systems,  and  those  that  actually  were  collected,  in  FBE-K.  The  gap 
between  what  was  desired  and  realized  is  substantial.  Measures  that  would  go  far  toward 
removing  such  discrepancies  in  future  experimentation  include: 

•  A  requirement  for  system  participation  in  an  experiment  is  the  system  incorporation  of 
tools  that  would  log,  identify  and  timestamp  all  significant  operator  actions. 
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•  Data  logging  in  a  format  that  is  easily  manipulated  for  post  experiment  analysis. 

•  Pre-experiment  integration  testing  include  the  validation  of  the  data  logging  applications 
as  an  objective. 

The  data  that  would  be  captured  by  such  logging  tools  are  necessary  for:  an  objective  analysis  of 
the  engagement  process,  the  assessment  of  the  contribution  of  individual  systems  to  the 
engagement  process  and  the  evaluation  of  the  perfonnance  of  individual  operators. 

Another  essential  aspect  of  objective  data  collection  is  the  time  synchronization  of  all  participant 
systems.  The  data  from  FBE-K  show  that  the  IRC  and  ADOCS  time  stamps  were  several 
minutes  out  of  synchronization. 

Required  and  Realized  TST  Engagement  Event  Data  from  FBE-K 


Event 

System 

Collected 
in  FBE-K? 

Comments 

Target  sensing 

JSAF 

N 

For  simulated  sensings 

Target  detection 

GISRC,  TES-N 

N 

Track  creation 

Target  nomination  (start) 

GISRC,  TES-N 

N 

Target  nomination 
(complete) 

GISRC,  TES-N 

N 

Nomination  transmitted 

GISRC,  TES-N 

N 

Nomination  rec’d 

ADOCS 

Y 

Rec’d  time  in  Mission  History  and  on 
Targeting  tab  often  disagree. 

Nomination  rec’d 

PTW 

N 

Weapon-Target  Pairing 

ADOCS 

Y 

Request  georefmement 

ADOCS 

N 

Georefinement  not  a  factor  in  FBE-K 

Start  georefmement 

PTW 

N 

Complete  georefinement 

PTW 

N 

Georefinement  result 
transmitted 

PTW 

N 

Georefinement  result 
received 

ADOCS 

N 

Coordination  block 
actions 

ADOCS 

Y 

Many  events.  Inconsistencies  in 
many  cases  in  the  ADOCS  data 

TLAM  route  request 

ADOCS 

N 

TLAM  route  request 
received 

RPM 

N 

Initiate  route 
computation 

RPM 

Y 

Route  computation 
complete 

RPM 

Y 

Transmit  route 

RPM 

Y 

Route  received 

ADOCS 

N 

Fire  When  Ready  (WRD) 

ADOCS 

Y 
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Fire  command 

ADOCS,  JSAF 

Y/N 

SNN  did  not  log  Fire  events 

Impact 

JSAF 

Y 

Gaps  in  the  data 

BDA  report 

ADOCS 

Y 

4.5  CONOPS  AND  TTP  EMPLOYED 

Neither  CONOPS  nor  SOP  were  available  for  TST  processes  that  matched  the  C2  processes  for 
FBE-K.  It  was  decided  to  use,  as  much  as  was  practical,  the  draft  PACAF  AOC  SOP.  The 
pertinent  section  of  that  document  to  this  experiment  is  Annex  F  to  Chapter  6,  Time-Critical 
Targeting  Team.  A  description  of  actions  perfonned  by  the  ISR  Section  and  Attack  Operations 
and  a  summary  of  the  essential  elements  of  the  process  follows. 


4.5.1  ISR  Section 

The  principal  role  of  the  ISR  Section  during  TCT  operations  was  to  lead  the  Find,  Fix,  Track, 

and  Assess  functions  of  the  F2T2EA  kill  chain.  Figure  3  provides  a  Information  Flow  diagram 

of  the  ISR  Section  observed  during  TT03.  Key  functions  of  ISR  Section  observed  during  TT03 

include: 

•  Conducted  Predictive  Battle  Space  Analysis  (PBA)  for  TCT  based  on  Intelligence 
Preparation  of  the  Battlespace  (IPB)  conducted  for  deliberate  planning/ATO  generation. 
[Note:  PBA  was  notional  during  the  exercise.  Discussions  between  TCT  ISR  Section  at 
AOC  and  JTF  ISR  staff  on  BLUE  RIDGE  was  limited  during  the  CPX] 

•  Conducted  dynamic  sensor  re-tasking  for  those  assets  not  under  direct  collection 
management  authority  of  the  TCT  team. 

[Note:  TT03  process  required  ISR  Section  to  request  sensor  re -tasking  through  the  JECG 
and  USS  BLUE  RIDGE.  In  real  world,  the  SIDO  would  have  capability/authority  to 
reposition  sensors  to  Find/Fix  TST.  If  JFACC  were  afloat  then  ISR  Section  would  have 
reach-back  capability  to  support  dynamic  sensor  re-tasking]. 

•  Tracked  ISR  data  and  provide  TST  nomination  to  the  TCT  Chief  for  valuation 

•  Coordinated  with  external  agencies  to  fully  integrate  all  possible  ISR  capabilities  in  support 
of  TCT  (ELINT,  COMINT,  HUMINT,  IMINT) 

•  Ensured  track  quality  and  geo-location  support  desired  weapons  options  and  address  any  ID 
conflicts 

•  Tracked  TST’s  throughout  TST  “life-cycle”  and  maintain  situational  awareness  on  all  active 
TST’s. 

[Note:  Intelligence  information  regarding  TST’s  was  shared  between  the  BLUE  RIDGE 
TES-N  and  AOC  ISR-M.] 

•  Provided  support  to  Attack  Operations  Section  during  target  pairing  function  against  a 
particular  TST  (e.g.  Collateral  Damage  Assessment  (CD A),  Refined  Mensuration)  [Note:  In 
reality  the  AOC  (TST  Authority)  ISR  Section  would  conduct  CDA  and  target  mensuration 
prior  to  forwarding  TST  nomination  to  Attack  Operations,  however,  during  TT03  CPX,  CDA 
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was  requested  from  the  JECG  and  target  mensuration  was  sometimes  conducted  on  USS 
BLUE  RIDGE  before  sending  imagery  from  TES-N  to  ISR-M  (AOC)  for  TST  engagement] 

•  Compared  nominated  TST  to  daily  ATO  target  list 

•  Coordinated  Phase  II  BDA 

[Note:  SIDO  did  not  have  control  of  ISR  assets  during  the  exercise.  During  TT03,  all  BDA 
requirements  were  coordinated  through  the  Joint  Experiment  Control  Group  (JECG)  and  ISR 
Cell  on  USS  BLUE  RIDGE] 


4.5.2  Attack  Operations  Section 

The  principal  role  of  the  Attack  Operations  Section  during  TCT  operations  was  to  lead  the  target 
and  engage  function  of  the  F2T2EA  kill  chain.  During  TT03,  the  Deputy  CCO  was  tasked  as  the 
Attack  Operations  Chief  with  responsibility  of  coordinating  support  required  to  successfully 
attack  nominated  TST  with  AOC  personnel  (Airspace  Management,  10,  Tanker  Cell,  JAG,  Joint 
liaisons,  etc.).  Figure  4  provides  a  Infonnation  Flow  diagram  of  the  Attack  Operations  Section 
observed  during  TT03.  Key  functions  of  Attack  Operations  Section  observed  during  TT03 
include: 

•  Received  the  approved  TST  nominations  from  the  TCT  Chief  and  coordinated  with  the  ISR 
Section  (Targets)  to  develop  a  list  of  available  assets  capable  of  attacking  the  target. 

•  Coordinated  with  AOC  liaison  elements  (Battlefield  Coordination  Detachment  (BCD), 
MARLO,  NALE,  SOLE,  for  availability  of  alternative  attack  options  for  TST 
engagement/attack.  [Note:  MARLO  or  SOLE  representatives  did  not  participate] 

•  Coordinated  with  10  Cell  for  potential  non-kinetic  kill  solutions.  [Note:  This  was  not 
observed  during  TT03  but  step  was  identified  during  discussions  with  TCT  Chief  and  Attack 
Operations  Chief] 

•  Provided  TCT  Chief  with  a  prioritized  attack  asset  list  and  package  options  for  TST. 

•  Provided  TCT  Chief  with  JAG  perspective  on  TST’s  prior  to  requesting  final  approval  from 
JFACC  for  engagement. 


4.5.3  TCT  Process  Summary 

1.  Based  on  Commander’s  Guidance,  ISR  assets  will  be  resourced  on  ATO.  Emerging 
targets  (ELINT,  COMINT,  HUMINT,  IMINT,  etc.)  commence  TCT  process. 

2.  Ensure  TST  Targeting  Matrix  and  ROE  is  available  at  JIC  (BLR),  JAOC  TST  Cell  (BLR) 
and  AOC  TCT  Cell  (Hickam) 

3.  As  tippers  (sensor  cues)  flow  in  from  a  variety  of  sources,  the  ISR  Section  (SIDO) 
prioritizes  which  targets  are  potentially  valid  TST’s.  The  SIDO  enters  potential  targets 
on  the  ‘Emerging  Target  List’  and  requests  the  track  data  manager  to  create  a  JTIDS  3.5 
track  if  a  JSTARS  unit  has  not  already  created.  The  track  data  manager  in  the  ISR 
Section  will  work  with  the  Joint  Stars  Work  Station  (JSWS)  operator  to  ensure  tracks  are 
created,  updated,  and  dropped  as  appropriate. 
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[NOTE:  During  TT03,  AOC  TST  Cell  (Hickam)  received  initial  target  nominations  from 
the  ship  and  acknowledged  receipt  to  the  JAOC  TST  Cell  (BLR)  via  IWS  Chat,  SIPRnet 
email  or  Voice  Comm] 

4.  Targets  not  categorized  as  TST’s  will  be  forwarded  to  the  Senior  Offensive  Duty  Officer 
(SODO)  for  potential  retasking  of  current  ATO  assets  to  accommodate,  or  processed 
back  through  Combat  Plans  for  inclusion  in  subsequent  ATO’s. 

5.  SIDO  directs  TCT  personnel  (targets  and  current  situation)  to  conduct  a  Predictive 
Battlespace  Analysis  (PBA)  based  on  sensor  cue(s).  PBA  could  be  considered  a  more 
refined  IPB  of  the  specific  TST  location.  Collateral  damage  assessment  is  conducted  to 
ensure  TST  engagement  will  not  violate  Commander’s  Guidance  or  ROE. 

6.  SIDO  directs  Collections  Manager  to  modify  collection  plans,  as  required  to  cross¬ 
correlate  initial  sensor  contact.  SIDO  must  coordinate  with  TCT  Chief  and  CCO  prior  to 
re-tasking  sensors  on  current  ATO. 

7.  SIDO  evaluates  sensor  data  collected.  If  target  is  a  TST  identified  on  Joint  Integrated 
Prioritized  Target  List  (JIPTL),  the  SIDO  will  nominate  the  target  to  the  dynamic  target 
list. 

8.  After  a  target  is  nominated  to  the  dynamic  target  list,  the  TCT  Chief  will  assign  the  target 
a  team  in  the  Attack  Operations  Section. 

[NOTE:  Real  world  operations  typically  include  three  attack  coordination  teams  to 
handle  multiple  high  priority  TST’s  simultaneously.  CCO  and  TCT  Chief  will  adjust  the 
number  of  teams  as  required  by  the  operational  tempo.  Instead  of  creating  teams  with 
stovepipe  focus  (geographic  areas  or  specific  target  sets),  each  team  should  be  able  to 
flex  to  any  geographic  area/target  set  as  directed  by  the  SIDO  and  TCT  Chief] 

9.  The  attack  coordination  team  is  responsible  for  friendly  deconfliction,  coordination  with 
SOLE/BCD/MARLO  for  attack  options,  asset  nomination  based  on  threat,  weather, 
response  time,  weapons  effect,  airspace  deconfliction,  Positive  Identification  (PID), 

Rules  of  Engagement  (ROE),  and  point  mensuration,  as  required. 

10.  The  attack  coordinator  works  closely  with  the  Targeteer  (ISR  Section)  to  ensure 
mensuration  and  collateral  damage  assessment  is  conducted  and  current;  then  completes 
an  electronic  checklist  for  the  attack  as  posted  on  the  shared  view  of  selected  chat  room 
application.  When  data  form  is  complete,  the  attack  coordinator  presents  the  attack  plan 
to  the  TCT  Chief  for  approval.  The  TCT  Chief  will  review  and  present  recommendations 
to  the  CCO,  AOC,  and  JFACC. 

1 1 .  In  parallel  to  the  attack  option  development,  the  SIDO  coordinates  with  Collections 
Manager  and  Current  Situation  to  identify  ISR  resources  required  for  a  Phase  II  BDA  and 
plans  BDA  mission(s),  if  required.  The  primary  BDA  will  be  conducted  and  verified  by 
platforms  conducting  the  strike  (Phase  I).  However,  if  Phase  I  BDA  is  unsuccessful,  the 
SIDO  will  provide  recommended  approach  to  dynamically  retask  assets  to  conduct  Phase 
II  BDA. 

12.  Once  the  TST  strike  package  is  approved  by  the  JFACC,  the  TCT  Chief  directs  the  C2 
duty  officer  to  pass  the  tasking  via  SATCOM  TCT  net  to  the  C2  package  Commander  in 
the  aircraft. 

[Note:  All  approved  strike  packages  were  forwarded  through  JECG  during  TT03  CPX] 

13.  The  attack  coordinator  ensures  the  strike  package/target  information  is  forwarded  to  the 
appropriate  duty  officer  (track  data  manager)  to  pass  up  to  the  attack  aircraft. 
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[Note:  Assumes  that  weapon  target  pairing  is  Air  Force  strike  aircraft.] 

14.  The  track  data  manager  sends  a  9.0  tasking  message  to  the  aircraft  and  works  with  the 
surface  track  coordinator  and  the  JSWS  operator  to  ensure  the  track  is  updated  with 
accurate  coordinates  and  elevation. 

15.  The  C2  Commander  on  Aircraft  will  conduct  Phase  1  BDA  and  pass  infonnation  to  the 
C2  Duty  Officer  who  informs  TCT  Chief  of  the  results. 

16.  The  TCT  Chief  coordinates  with  the  SIDO,  CCO  and  JFACC  to  decide  if  Phase  II  BDA 
or  re-strike  option  is  required. 
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5.0  RESULTS 


As  was  stated  in  the  Reconstruction  section,  FTX  results  were  strongly  influenced  by  equipment 
and  manning  issues.  This  makes  it  difficult  to  provide  any  results  concerning  TST  processes. 
Thus,  the  focus  here  is  not  only  on  answering  initiative  questions  by  also  includes  a  significant 
amount  concerning  equipment  and  experimentation  improvements. 


5.1  COALITION  INITIATIVE  RESULTS 

5.1.1  Coalition  Results  Details  and  Summary 

The  following  table  presents  the  FTX  MSEL  targets  used  to  compare  US  and  Coalition  ADOCS 
mission  histories.  Mission  histories  are  created  in  ADOCS,  which  lists  the  steps  taken  to 
prosecute  a  target.  They  are  listed  by  time  and  give  an  historical  view  of  when  an  event,  such  as 
the  firing  of  munitions,  happened.  The  targets  were  chosen  based  on  description  and  location 
stated  in  the  MSEL.  Exact  coordinates  and  times  were  not  given. 

The  table  compares  data  from  Blue  Ridge,  Coalition  and  ANZAC  with  data  from  Newport.  Data 
was  not  recorded  for  Newport  on  April  29,  2003.  Coalition  data  was  not  recorded  on  April  30, 
2003.  And  there  was  no  data  from  ANZAC  from  April  28  to  May  1,  2003.  Blue  Ridge  data  was 
used  to  compare  with  Coalition  data  on  April  29,  2003  in  lieu  of  the  unrecorded  Newport  data. 
Blue  Ridge  and  Newport  ADOCS  are  central  to  the  other  ADOCS  involved  in  the  experiment 
and  are  assumed  to  have  the  same  data.  Targeting  coordinates,  discussed  in  the  table,  were 
retrieved  from  the  Fire  Mission  menu  in  ADOCS  for  the  specific  target. 

Target  Mission  History  Comparison  with  Newport  (NPT)  ADOCS 
MSEL  Target  Blue  Ridge  (BLR)  Coalition  ANZAC 


28-1  AB0021 


Mission  history 
similar  to  NPT, 
except  for  an  extra 
line  in  BLR 


No  mission  history.  Targeting 
coordinate  is  the  same  as  NPT, 
located  on  water.  Coordinate  was  No  data  collected 
later  changed  in  NPT,  but  did  not  from  ANZAC 
update  in  Coalition  ADOCS.  Same 
acquisition  time. 


AB0022 


Mission  history  same 
as  NPT 


No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 


No  data  collected 
from  ANZAC 


AB0023 


Mission  history  same 
as  NPT 


No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 


No  data  collected 
from  ANZAC 
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No  mission  history.  Targeting 

AB0024 

Target  not  in  BLR 
data 

coordinate  was  changed  in  NPT, 
looks  like  the  same  location  on  map 
between  Coalition  and  Newport. 

No  data  collected 
from  ANZAC 

Same  acquisition  time. 

AB0027 

Mission  history 
similar  to  NPT, 

Restrike  of  Target  #  AB0024.  No 

No  data  collected 

except  for  two  lines 

mission  history 

from  ANZAC 

in  BLR 

29-1 

TB0039 

No  data  collected 
from  Newport 

Target  not  in  Coalition,  using  BLR 
data  to  compare 

No  data  collected 
from  ANZAC 

TB0040 

No  data  collected 

Target  not  in  Coalition,  using  BLR 

No  data  collected 

from  Newport 

data  to  compare 

from  ANZAC 

29-2 

AB5002 

No  data  collected 

Target  not  in  Coalition,  using  BLR 

No  data  collected 

a/b 

from  Newport 

data  to  compare 

from  ANZAC 

AB5007 

No  data  collected 

Target  not  in  Coalition,  using  BLR 

No  data  collected 

from  Newport 

data  to  compare 

from  ANZAC 

AB5012 

No  data  collected 

Target  not  in  Coalition,  using  BLR 

No  data  collected 

from  Newport 

data  to  compare 

from  ANZAC 

AB5013 

No  data  collected 

Target  not  in  Coalition,  using  BLR 

No  data  collected 

from  Newport 

data  to  compare 

from  ANZAC 

TB0042 

No  data  collected 
from  Newport 

No  mission  history.  Targeting 
coordinate  same  as  BLR  data.  NLT 
time  not  updated 

No  data  collected 
from  ANZAC 

GEO  149 

No  data  collected 
from  Newport 

No  mission  history.  Targeting 
coordinate  and  time  same  as  BLR 
data. 

No  data  collected 
from  ANZAC 

30-1 

TB0051 

Mission  history 
details  in  BLR  is  not 

No  data  from  Coalition 

No  data  collected 
from  ANZAC 

all  in  NPT  ADOCS 

Mission  history 
similar  to  NPT, 

30-2 

AB5037 

except  missing  two 
entries  from  BLR. 

No  data  from  Coalition 

No  data  collected 
from  ANZAC 

Entries  same  times, 
out  of  order  between 

NPT  and  BLR 
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Mission  history 
TB0052  details  in  BLR  is  not 

No  data  from  Coalition 

No  data  collected 
from  ANZAC 

all  in  NPT  ADOCS 

Mission  history 
TB0053  details  in  BLR  is  not 

No  data  from  Coalition 

No  data  collected 
from  ANZAC 

all  in  NPT  ADOCS 

1-1 

„„ „ .  , .  Mission  history  same 
GEO  164 

as  NPT 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

No  data  collected 
from  ANZAC 

Mission  history 

No  mission  history.  Targeting 

No  data  pnllppfpd 

TB0059  details  in  BLR  is  not 

coordinate  and  time  same  as  NPT 

from  ANZAC 

all  in  NPT  ADOCS 

data. 

1-2 

a  Demo  Mission  history  same 

At)  jU  / Z  TVTT^'T' 

as  NPT 

Target  not  in  Coalition  data 

No  data  collected 
from  ANZAC 

.  Demo  Mission  history  same 
as  NPT 

Target  not  in  Coalition  data 

No  data  collected 
from  ANZAC 

Mission  history 

AB5074  similar  to  NPT, 
except  tor  an  extra 

Target  not  in  Coalition  data 

No  data  collected 
from  ANZAC 

line  in  BLR 

1-3 

Mission  history 

rvm .  ~  similar  to  NPT, 
uXUJiz  ,  „ 

except  tor  extra 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

No  data  collected 
from  ANZAC 

entries  in  BLR 

Mission  history 

GX0314  similar  to  NPT. 

except  tor  an  extra 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

No  data  collected 
from  ANZAC 

line  in  BLR 

„vn. ,  ,  Mission  history  same 

LrXUJ  1 0  XTta^f 

as  NPT 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

No  data  collected 
from  ANZAC 

Mission  history 

2-1  GX0337  details  in  BLR  is  not 

all  in  NPT  ADOCS 


No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 


No  data  collected 
from  ANZAC 


Mission  history 
GX0338  details  in  BLR  is  not 
all  in  NPT  ADOCS 


No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 


No  data  collected 
from  ANZAC 
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GX0341 

Mission  history 
similar  to  NPT, 
except  for  two  lines 
in  BLR 

No  mission  history.  Targeting 
information  in  Coalition  has  more 
detail  that  in  NPT  mission  history. 

This  may  be  part  of  another 
mission,  GX0338  based  on  similar 
time  frame  and  coordinates. 

No  data  collected 
from  ANZAC 

TB0065 

Mission  history 
details  in  BLR  is  not 
all  in  NPT  ADOCS 

No  mission  history.  NPT  mission 
history  has  limited  information. 
Cannot  compare  coordinates  and 
time  with  Coalition  targeting 
infonnation. 

No  data  collected 
from  ANZAC 

2-2  AB5088 

Mission  history 
similar  to  NPT, 
except  for  the  order 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

Target  not  in 
ANZAC  data. 

AB5089 

No  mission  history 

No  mission  history.  NPT  has  no 
mission  history  to  compare  to 
Coalition.  This  is  a  restrike  of 
TB0063. 

Target  not  in 
ANZAC  data. 

TB0063 

Target  not  in  BLR 

No  mission  history.  Targeting 
coordinate  and  time  same  as  NPT 
data. 

No  mission  history 

TB0064 

Mission  history 
details  in  BLR  is  not 
all  in  NPT  ADOCS 

Target  not  in  Coalition  data 

Target  not  in 
ANZAC  data. 

2-3  AA0370 

Mission  history 
similar  to  NPT, 
except  for  an  extra 
line  in  BLR 

Detailed  mission  history  in 
Coalition.  NPT  mission  history  is 
limited  to  status  changes. 

Detailed  mission 
history  in  ANZAC. 

AA0373 

Same  as  NPT,  BLR 
mission  history  is 
limited  to  2  status 
changes. 

Detailed  mission  history  in 
Coalition.  NPT  mission  history  is 
limited  to  2  status  changes. 

Detailed  mission 
history  in  ANZAC. 

Comparing  Newport  target  mission  histories  with  Blue  Ridge’s  mission  histories  shows  that 
there  are  differences  between  the  two  US  ADOCS.  Some  mission  histories  for  the  same  target 
between  Newport  and  Blue  Ridge  were  similar  except  for  one  or  two  lines.  At  other  times,  such 
as  target  TB0065,  not  all  information  is  shared  between  the  two  systems.  However,  the 
information  that  is  shared  is  the  same. 
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Comparing  the  same  Coalition  targets  to  US  targets  shows  that  complete  mission  histories  is  not 
exchanged  between  US  and  Coalition  ADOCS.  Most  of  the  targets  did  not  have  any  mission 
histories  in  Coalition.  It  was  not  until  MSEL  2-3,  targets  AA0370  and  AA0373,  that  Coalition 
had  mission  histories;  but  only  a  few  lines  of  over  20  lines  in  Coalition  were  exchanged  with  the 
US  ADOCS  for  both  targets. 


Tabulation  of  Mission  Hist 

tory  (MH)  Comparison 

Blue  Ridge 

Coalitio 

n 

ANZAC 

Different  MH  compared  to 

NPT 

17 

21 

3 

No  Targets 

2 

10 

3 

No  Data 

8* 

4 

29 

MH  similar  to  NPT 

8 

0 

0 

Total  MSEL  Targets 

35 

35 

35 

*  No  data  from  Newport  to  compare  with  Blue 

7idge  data. 

Missing  targets  and  mission  histories  may  be  attributed  to  Radiant  Mercury  Guard  (RMG). 
Radiant  Mercury  Guard  acted  as  a  filter  of  information  exchanged  between  US  and  Coalition. 
However,  there  are  other  issues  that  could  affect  the  data.  Based  on  the  descriptions  of  problems 
observed,  there  are  several  possible  reasons  that  discrepancies  could  exist  in  the  ADOCS  data 
according  to  Gary  O'Neilin  of  General  Dynamics: 

1 .  Network  problems  may  have  occurred,  though  this  is  the  most  unlikely  one  because  of 
the  way  ADOCS  Communication  Server  works.  When  the  connection  between  two  ADOCS 
nodes  is  broken,  the  sending  nodes  queue  up  all  messages  going  out  to  the  node  that  is  down. 
When  the  connection  is  re-established  all  the  messages  to  include  the  messages  that  may  have 
been  sent  during  disconnection  are  resent. 

2.  Not  all  locations  see  every  mission.  It  is  dependent  upon  the  way  the  architecture  is 
set  up.  In  most  FBE  architecture  there  is  one  ship  that  sees  all  missions  that  are  going  to  be 
fired;  in  this  case  it  was  the  Blue  Ridge.  The  E2X,  DDX,  Coalition  and  ANZAC  were  to  my 
knowledge  shooters;  this  means  they  only  see  missions  that  are  pushed  to  them  by  the  Blue 
Ridge  or  missions  that  are  detected  by  their  organic  sensors.  There  is  no  reason  for  every 
shooter  to  see  every  mission  and  most  commanders  don’t  want  to  see  things  that  they  have  no 
control  over.  It  just  clutters  up  their  picture  and  muddles  their  mission. 

3.  The  resetting  of  the  databases  could  be  a  cause  of  the  problem  if  network  connections 
were  dropped  prior  to  all  the  messages  being  sent  to  the  proper  location  for  backup. 

4.  There  has  been  a  problem  detected  with  mission  history  in  the  newer  versions  of 
ADOCS,  but  confirming  it  in  the  version  that  was  used  in  the  FBE-world  has  not  been  done. 

The  problem  appears  to  cause  additional  lines  of  text  from  one  node  as  well  as  shows  the  mission 
history  in  various  orders  between  nodes  even  when  using  the  same  viewing  type  such  as  Time. 

In  closing  since  I  was  not  present  at  FBE  it  is  very  hard  to  determine  the  exact  cause  of 
loss  of  data,  but  in  previous  FBEs  I  have  done,  the  above  items  have  been  some  of  the  things  that 
have  given  us  grief.” 
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Despite  missing  targets  and  incomplete  mission  histories  from  the  ADOCS  data,  vANZAC  COP 
was  adequate  to  support  engagement.  Based  on  observations  made  by  Dr.  Darren  Sutton  in  the 
Coalition  cell,  vANZAC  was  aware  of  all  surface  and  ground  targets  within  ADOCS.  Their 
awareness  was  also  made  possible  through  chat  and  GCCS-M. 

The  reasons  for  missing  targets  and  incomplete  mission  histories  have  not  been  identified;  they 
may  have  been  caused  by  network  problems  and  multiple  instances  of  ADOCS  down  times  as 
stated  in  section  5.1.2.  RMG  may  also  have  contributed  to  the  missing  data. 

To  prevent  future  data  problems  ensure  that  network  problems  and  ADOCS  issues  are  corrected. 
Future  data  collection  should  be  coordinated  between  the  users  of  ADOCS  using  agreed  upon 
format.  These  actions  would  facilitate  proper  analysis  of  the  fires  processes. 


5.1.2  Coalition  Participants  Fires  Observations 

The  following  are  the  observations  of  CMDR  Cunningham,  RAN  and  CDR  Davis,  USNR 

Tuesday,  April  29,  Observations 

1.  According  to  Coalitions  Fires  in  NPT,  if  VANZAC  edits  ANZ  tab  (Missions 
Coordination  Manager)  it  fires  the  mission.  They  aren’t  editing  the  ANZ  tab. 

2.  FDR  Block  (Missions  Coordination  Manager)  stayed  yellow  on  BLR  ADOCS  side. 
Coalition  Fires  side  of  ADOCS  after  weapons  release  was  showing  green.  Target  was 
TB0041. 

3.  VANZAC  requested  guidance  on  number  of  ERGM  rounds  to  fire.  Cannot  specify 
number  of  rounds  in  ADOCS.  Does  unit  or  XP  detenninate  the  number  of  rounds  to  fire. 

4.  VANZAC  was  unclear  on  tab  protocol.  XP  developed  and  disseminated  tab  protocol 
during  the  exercise,  but  tab  protocol/documentation  required  prior  to  STARTEX  to 
clarify  requirements  for  exercise  participants. 

5.  VANZAC  intermittently  dropped  out  of  GCCS. 

6.  Air  gap  latency  didn’t  appear  to  hinder  VANZAC  response  to  chat. 

7.  VANZAC  achieved  chipped  image  electronic  transfer  into  FBE-K  target  folders  at  NPT 
for  web  dissemination. 

8.  Multiple  ADOCS  system  down  times  hindered  play.  Chat  successful  in  engineering 
work  around  during  ADOCS  outages. 

Wednesday,  April  30,  Observations 

9.  Fires  Mission  Manager  FRD  tab  doesn’t  turn  green  after  vANZAC  fires. 

10.  Fires  Mission  Manager  E2X,  DDX,  ANZ,  ADC  and  JIC  tabs  reset  to  white  for  every 
RMG  transmission  -  work  around  is  for  ADOCS  operator  BLR  to  edit  tabs. 

1 1 .  JTST  Manager  MSN  tab  is  not  turning  to  green  when  weapon  is  released. 

12.  Not  able  to  select  weapons-target  pairing  from  options  menu  -  unable  to  assign  ANZAC- 
ERGM  weapon-target  pairing  for  AA0305. 

13.  Two  targets  (AB5035  and  AB5035)  result  from  the  re-nomination  of  AA0305. 

14.  ADOCS  JOC  Station  3  is  unstable. 
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Thursday,  May  1,  Observations 

15.  Multiple  ADOCS  system  down  times  hindered  play.  Chat  successful  in  engineering 
work  around  during  ADOCS  outages. 

16.  Air  gap  latency  didn’t  appear  to  hinder  VANZAC  response  to  chat. 

17.  Confirmed  that  RMG  interchange  between  high  and  low  sides  deleted  EZX,  DDX,  ANZ, 
JIC,  and  ADC  tabs  information  in  Missions  Coordination  Manager  with  each 
transmission.  Work  around  is  for  low  side  to  pen  and  paper  ADOCS  play  while  high  side 
communicates  process  via  chat  and  updates  ADOCS. 

Friday,  May  2,  Observations 

18.  Multiple  ADOCS  system  down  times  hindered  play.  Chat  successful  in  engineering 
work  around  during  ADOCS  outages. 

19.  XP  distributed  refined  process  (including  tab)  protocols.  The  refined  protocol  was  used 
to  prosecute  targets. 

20.  Air  gap  latency  didn’t  appear  to  hinder  VANZAC  response  to  chat. 

21.  RMG  interchange  between  high  and  low  sides  continued  to  delete  EZX,  DDX,  ANZ,  JIC, 
and  ADC  tabs  information  in  Missions  Coordination  Manager  with  each  transmission. 
Work  around  is  for  low  side  to  pen  and  paper  ADOCS  play  while  high  side 
communicates  process  via  chat  and  updates  ADOCS. 

22.  RMG  interchange  problems  detracted  significantly  from  vANZAC  participation  in  an 
engagement  mode  in  the  fires  network. 

23.  BLR  network  didn’t  appear  suitable  to  host  ADOCS.  Slow  speed  of  ADOCS  and  system 
crashes  prevented  full  utilization  of  the  system. 

24.  Although  air  gap  latency  didn’t  significantly  hinder  communications  with  vANZAC,  the 
use  of  a  third  party  “air  gap”  was  cumbersome  and  did  result  in  ambiguity. 

Amplifying  infonnation: 

•  Occasionally,  use  of  the  zoom  function  caused  the  ADOCS  system  to  crash. 

•  ADOCS  map  updates  occurred  every  3  minutes.  This  was  not  fast  enough  in  some  cases. 

•  How  does  one  know  when  a  target  has  been  pushed  to  them? 

•  ADOCS  computer  setups  should  be  standardized. 

•  The  chat  room  rules  were  not  adequately  established. 

•  ADOCS  was  not  providing  indication  of  target  being  hit  fast  enough  to  allow  efficient 
control  of  ISR  assets  for  BDA. 


5,1.3  Coalition  Partner  Observations 

While  coalition  partner  observations  occurred  at  two  widely  geographically  separated  locations, 
at  the  Defense  Science  and  Technology  laboratory  in  Fern  Hill,  Australia  and  the  Navy  Warfare 
Development  Command  Modeling  and  Simulation  laboratory  in  Newport,  Rhode  Island,  a  single 
combined  set  of  observations  is  presented  here.  This  is  reasonable  because,  at  least  for  ADOCS, 
both  locations  were,  in  theory  and  as  far  as  was  tested  during  execution  in  practice,  viewing  the 
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same  data.  It  is  however  important  to  note  that  there  were  differences  in  the  situational 
awareness  at  the  two  sites  resulting  from  access,  or  lack  of  it,  to  other  systems  at  the  two  sites. 
GCCS-M  and  GISRC  were  available  in  Australia,  but  not  in  the  Coalition  Cell  in  Newport,  while 
US  SECRET  NOFORN  network  including  Web  pages,  IRC  chat  and  Voice  over  IP  (VoIP)  were 
accessible  to  the  coalition  in  Newport,  but  obviously  not  directly  in  Australia. 

Given  the  detailed  reporting  of  technical  observations  related  to  the  coalition  initiative  elsewhere  in 
this  report  the  following  observations  are  reported  in  summary  fonn. 

C4I  Systems 

ADOCS  Integration :  The  key  technical  issue  facing  the  coalition  was  its  ‘seamless  integration’ 
as  a  node  within  a  distributed  fires  network.  While  some  level  of  integration  was  achieved  it  was 
certainly  not  seamless  and  this  was  most  evident  with  ADOCS,  which  was  intended  to  be  the 
principle  tool  to  support  the  command  and  control  of  nodes  in  the  fires  network. 

Despite  continued  efforts  throughout  both  the  final  operational  sequence  diagram  (OSD)  testing 
period  and  the  rehearsal  period  between  the  CPX  and  FTX  phases  the  full  integration  of  ADOCS 
across  the  boundary  between  the  SECRET  US  NOFORN  and  SECRET  AUSCANUKUS 
Releasable  networks  was  not  achieved. 

While  the  majority  of  the  problems  initially  observed  during  final  OSD  testing  were  resolved, 
others,  including  most  notably  the  over-writing  of  the  colored  boxes  in  the  Fires  Manager,  did 
not  become  apparent  until  execution,  by  which  time  their  resolution  was  impractical,  if  not 
impossible.  Efforts  to  resolve  ADOCS  issues  continued  into  the  execution  phase,  but  to  allow  the 
operational  experimentation  objectives  to  be  explored  a  work  around  involving  chat  coordination 
of  fires  command  and  control  was  implemented. 

While  the  reasons  for  the  unavailability  of  ADOCS  developers  during  the  integration  periods  is 
understood  and  the  excellent  support  provided  by  NWDC  contract  personnel  throughout  the 
integration  and  exercise  periods  is  greatly  appreciated,  their  limited  experience  with  ADOCS  and 
an  understandable  lack  of  access  to  its  code  seriously  impacted  their  ability  resolve  these 
problems.  The  availability  of  an  ADOCS  developer  during  the  final  OSD  testing  did  assist  in 
resolving  a  number  of  issues,  however  their  remote  assistance  during  the  execution  phase  was 
less  helpful. 

ADOCS  Network  Performance :  As  the  FTX  phase  progressed  an  increase  in  the  latency  of 
updates  in  the  ADOCS  network  became  apparent.  When  initially  reported  during  execution  day 
Wednesday  April  30  it  prompted  a  check  of  the  overall  network  performance,  which  failed  to 
reveal  any  issues. 

During  the  execution  day  Thursday  May  1  the  latency  became  extreme  and  as  was  noted  during 
the  presence  of  the  Distinguished  Visitors  at  Fern  Hill  exceeded  ten  (10)  minutes  from  an  action 
reportedly  being  taken  on  the  BLR  to  an  update  reflecting  that  action  being  seen  at  either  of  the 
Coalition  ADOCS  systems. 
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A  post  experiment  review  of  the  network  architecture  deployed  for  FBE-K  suggests  that  this 
obviously  unacceptable  latency  was  the  result  of  a  combination  of  the  topography  of  the  ADOCS 
server  network  resulting  in  a  choke  point  and  the  underlying  protocol  for  ADOCS 
communications,  which  ironically  was,  designed  to  service  disadvantaged  users. 

There  appeared  to  be  some  degree  of  correlation  between  increased  latency  of  the  ADOCS 
network,  the  duration  that  it  had  been  operating  without  restart  and  correspondingly  the  number 
of  target  nominations  accumulated  in  the  target  list.  Consequently  the  more  frequent  ‘reboots’  of 
the  ADOCS  servers  early  in  the  FTX  as  a  consequence  of  communications  network  issues  and 
attempts  to  resolve  continuing  ADOCS  issues  may  have  masked  these  effects.  That  being  said 
the  number  of  targets  in  the  track  list  never  exceeded  a  couple  of  hundred,  which  was  reported  to 
be  trivial  for  an  operational  ADOCS  network. 

GCCS-M :  With  rare  exceptions,  induced  by  network  outages,  the  GCCS-M  system  functioned 
fully  effectively.  The  ability  to  transfer  data  between  GCCS-M  and  JSAF  as  a  means  of 
importing  and  exporting  relevant  entities  between  simulated  and  real  worlds  was  both  crucial 
and  highly  successful. 

GISRC:  The  operation  of  GISRC  was,  with  one  critical  exception,  reported  to  be  very  successful. 
There  is  however  a  disconnect  between  the  reported  operator  experience  in  Fern  Hill  and  the 
recorded  data. 

The  operator  reports  indicate  that  target  nominations  were  routinely  sent  from  GISRC,  via  secure 
e-mail,  to  the  ANZAC  ADOCS  system.  With  the  exception  of  when  this  was  attempted  during 
the  presence  of  the  Distinguished  Visitors  on  execution  day  May  1,  this  was  reported  as 
successful.  Unfortunately,  these  observations  are  not  supported  by  the  data  recorded  at  various 
locations,  as  no  ‘GA’  (GISRC  ANZ)  targets  are  recorded.  Further,  as  the  data  from  the  ANZAC 
ADOCS  is  unavailable  for  analysis  it  is  not  possible  to  determine  the  origin  of  this  problem. 

Radiant  Mercury  Guard :  To  bridge  the  security  boundary  between  the  SECRET  US  NOFORN 
and  SECRET  AUSCANUKUS  Releasable  networks  an  approved  guard  device,  a  Radiant 
Mercury  Guard  (RMG),  was  employed.  Given  tight  budget  constraints  and  equally  tight  time 
lines  to  accredit  the  use  of  this  device  it  was  decided  during  the  Initial  Planning  Conference  to 
‘re-use’  a  previously  approved  rule  set.  Without  this  decision  it  is  highly  likely  that  the  coalition 
initiative  would  not  have  proceeded. 

Unfortunately,  while  the  existing  rule  set  did  include  message  fonnats  for  the  essential  ADOCS 
(formerly  Land  Attack  Weapons  System  -  LAWS)  messages,  they  did  not  reflect  the  current 
version  of  those  messages.  The  understandable  inflexibility  of  the  security  accreditation  process 
meant  that  while  it  would  have  been  technically  to  update  the  rules,  it  was  not  allowable  to  do  so. 
As  a  consequence  not  all  of  the  data  that  was  being  sent  to  the  RMG  was  passed  through  to  the 
coalition  network. 


54 


With  respect  to  its  support  for  transmitting  the  Common  Operating  Picture  (COP)  via  the  Global 
Command  and  Control  System  -  Maritime  (GCCS-M),  the  Radiant  Mercury  Guard  was 
observed  to  function  fully  effectively. 

IKA  /CIE  Systems 

A  number  of  Infonnation  Knowledge  Advantage  (IKA)  or  more  accurately  Collaborative 
Information  Environment  (CIE)  tools  were  employed  in  FBE-K,  including  in  support  of  the 
Coalition  Initiative. 

Air  Gap :  While  Radiant  Mercury  Guard  was  used  to  filter  and  transfer  structured  messages 
between  the  SECRET  US  NOFORN  and  SECRET  AUSCANUKUS  Releasable  networks  the 
absence  of  an  approved  guard  device  to  do  so  for  unstructured,  human  centric  communications 
necessitated  the  inclusion  of  a  human-in-the-loop  ‘air  gap’. 

Staffed  by  principally  reserves  at  the  Coalition  Cell  in  Newport,  releasable  information  from 
Chat,  E-mail,  Voice  communications  and  Web  pages  was  reviewed  and  where  appropriate 
transferred  across  the  boundary  between  the  networks. 

While  far  from  ideal  this  function  was  crucial  to  the  success  of  the  Coalition  Initiative  and  served 
to  highlight  a  critical  issue  that  exists  in  terms  of  supporting  the  integration  of  coalition  partners. 

While  it  is  noted  that  technical  solutions,  for  example  ISSE  Guard,  do  exist  to  support  most,  but 
not  currently  all,  of  the  functions  achieved  by  human-in-the-loop  operations,  the  lead  time 
required  to  approve  the  use  of  such  devices,  like  those  for  RMG  were  so  long,  and  costly  as  to  be 
unworkable  in  FBE-K. 

Chat :  Given  the  difficulties  encountered  with  the  technical  integration  of  ADOCS  chat  provided 
a  crucial  backup  that  enabled  both  command  and  control  for  fires  coordination  and  interactions 
with  the  operator  of  the  UAVSim  to  direct  its  employment. 

Despite  their  best  efforts  the  reservists  were  unable  to  maintain  a  direct  transfer  of  messages 
across  the  air  gap.  While  latency  wasn’t  perceived  to  be  a  major  issue  this  ‘transcription’  of 
messages  was  reported  to  lead  to  some  ambiguity  between  the  XP  Cell  on  the  BLR  and  the 
ANZAC  command  team  in  Fern  Hill. 

E-mail :  A  relatively  low  volume  of  e-mail  was  sent  to  and  received  from  the  ANZAC,  which 
resulted  in  its  transfer  not  being  considered  too  burdensome.  However  due  to  the  arrangement  of 
air  gap  operator  stations  the  arrival  of  any  e-mail  did  result  in  an  increased  latency  of  chat 
transfers. 

The  majority  of  e-mails  came  from  the  ANZAC  and  these  contained  ‘chipped’  images  from  the 
GISRC  that  were  on-forwarded  to  an  address  that  automatically  populated  them  into  the 
corresponding  target  folder.  Later  in  the  execution  process  requests  for  mensurated  coordinates, 
based  on  these  images  were  passed  to  the  BLR. 
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VoIP'.  VoIP  communications  were  established  between  the  Coalition  Cell  in  Newport  and  the 
ANZAC  in  Fern  Hill.  The  Coalition  Cell  was  also  able  to  communicate  with  ah  US  nodes  that 
had  access  to  VoIP,  although  in  practice  this  use  was  far  more  limited. 

VoIP  provided  a  crucial  interactive  means  of  addressing  complicated  technical  issues,  particularly 
those  involving  the  problems  associated  with  ADOCS  integration.  While  there  were  initial  problems 
with  quality  of  service  due  to  the  configuration  of  some  of  the  network  infrastructure,  once  these 
were  resolved  VoIP  was  consistently  of  a  high  standard. 

VoIP  was  observed  to  work  very  successfully  for  technical  troubleshooting  and  also  demonstrated  its 
potential  to  be  used  for  tactical  coordination. 

Web-pages\  Despite  assurances  to  the  contrary  the  majority  of  the  information  published  on  the 
TT-03  and  associated  FBE-K  web  pages  were  not  marked  as  Releasable  AUSCANUKUS,  as  a 
consequence  during  the  rehearsal  period  and  into  the  first  days  of  the  FTX  only  limited 
information  was  able  to  be  transferred. 

Fortunately  a  reasonable  portion  of  the  information  was  static;  nonetheless  as  the  process  of 
transferring  data  was  relatively  complicated  it  still  took  a  single  operator  more  than  twenty 
minutes  to  transfer  the  very  limited  amount  of  daily  updated  infonnation  that  was  relevant  and 
releasable. 

As  with  chat  the  increasing  reliance  on  web  portals  to  provide  access  to  information  necessitates 
a  beher  solution  to  the  problem  of  integrating  coalition  partners. 

Networks 

CFBlnet :  A  cryptographically  isolated  bi-lateral  (AUS-US)  community  of  interest  (COI)  was 
established  within  the  Four-Eyes  (AU S/C  AN/UK/US)  enclave  of  the  Combined  Federated  Battle 
Laboratory  network  (CFBLnet).  With  a  nominal  network  capacity  of  1.5  MB  and  even  in  a  non- 
optimal  configuration  (IP  vs  ATM)  the  network  was  never  reported  to  have  saturated  and  was 
typically  observed  to  have  operated  at  approximately  50%  capacity. 

While  problems  were  experienced  with  the  delivery  and  maintenance  of  cryptographic  keys, 
including  with  the  roll  over  of  a  new  month,  these  problems  did  not  seriously  impact  the  execution 
of  the  coalition  initiative. 

FBEnet:  During  the  final  OSD  testing  period  significant  problems  were  experienced  establishing 
the  advanced  networking  capabilities  out  to  the  fleet  including  the  BLR.  While  these  were 
resolved  they  did  contribute  to  a  loss  of  valuable  time  in  which  to  address  issues  such  as  those 
that  arose  with  ADOCS  integration,  the  majority  of  which  only  became  apparent  when  BLR 
ADOCS  was  brought  into  the  system. 

FBEnet  stability  during  the  FTX  was  generally  reported  as  stable  and  the  available  bandwidth 
was  apparently  adequate  to  support  all  the  necessary  functions.  As  noted  already  an  investigation 
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of  the  network  traffic  prompted  by  the  observation  of  increased  latency  of  the  ADOCS  network 
did  not  reveal  broader  FBE  network  issues. 


Modeling  and  Simulation 

JSAF :  The  core  modeling  and  simulation  for  FBE-K  was  provided  by  Joint  Semi-Automated 
Forces  (JSAF)  operated  from  the  NWDC  Modeling  and  Simulation  laboratory,  Newport.  JSAF 
integrated  real  world  entities  ‘stripped’  from  GCCS-M  by  the  C4I  gateway  and  similarly 
populated  /  stimulated  GCCS-M  and  other  C4I  systems. 

With  one  or  two  exceptions,  when  it  appeared  to  crash,  JSAF  operated  successfully  throughout  all 
phases  of  FBE-K,  from  integration  testing  to  FTX  FINEX. 

UAVSim :  The  simulation  of  and  distribution  of  UAV  video  imagery  was  a  critical  component  of 
the  Coalition  Initiative  as  it  not  only  provided  the  necessary  realism  of  input  data  sources  for  the 
ANZAC  operators  it  also  provided  valuable  lessons  learned  as  far  as  the  issue  associated  with 
the  employment  of  such  capabilities. 

As  with  all  systems  temporary  losses  of  network  connectivity  compromised  the  function  of 
UAVSim  and  its  related  components  in  Fem  Hill,  however  these  problems  were  quickly  rectified 
once  the  network  was  re-established. 

The  ANZAC  operators  were  particularly  gratefully  for  the  support,  including  instruction  on 
operational  realities,  received  from  the  UAV  operator(s)  stationed  in  Newport. 

VMS'.  The  Virtual  Maritime  System  is  the  modeling  and  simulation  capability  used  to  create  the 
vANZAC.  While  its  functionality  in  FBE-K  was  relatively  limited  it  was  successfully  ‘federated’ 
with  the  core  JSAF  simulation  via  a  convoluted  arrangement  involving  multiple  instances  of 
JSAF  and  the  C4I  gateway;  the  RMG  and  a  Federation  Object  Model  /  Run  Time  Infrastructure 
(FOM/RTI)  Bridge. 

This  federation  successfully  proved  the  feasibility  of  incorporating  coalition  simulations,  from 
geographically  remote  sites,  into  the  FBE  modeling  and  simulation  architecture.  It  also  served  to 
identify  the  requirements  to  reduce  the  complicated  arrangement  of  systems  needed  to  achieve  such 
federations  in  the  future. 

Human  Factors 

Command  and  Control  Process'.  The  absence  of  a  ‘clearly  defined’,  ‘tactical  level’,  ‘step  by  step’ 
process  for  the  command  and  control  coordination  of  fires  was,  with  the  possible  exception  of 
the  technical  issues  associated  with  ADOCS  integration,  the  most  significant  issue  encountered 
by  the  Coalition  Initiative. 


The  provision  of  the  Fires  Manager  color  chart  and  the  associated  articulation  of  a  step-by-step 
process  for  fires  coordination  part  way  through  the  FTX  were  patently  to  late. 
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While  experimentation  with  the  fires  process  was  expected  the  majority  of  the  discussion  on  the 
topic  was  focused  more  on  understanding  process,  and  not  so  much  on  improving  it.  Operator 
confusion  at  the  ANZAC  and  at  the  Coalition  Cell  in  Newport  was  high,  leading  to  lengthy  chat  and 
VoIP  communications  to  seek  clarification,  where  as  these  communications  channels  should  have 
been  being  employed  primarily  for  actual  coordination. 

Operator  Training  /  Involvement:  The  presence  of  experienced  operators  and  technical  support 
personnel  both  in  Fern  Hill  and  to  a  lesser  extent  in  the  Coalition  Cell  in  Newport,  together  with 
the  presence  of  a  Liaison  Officer  in  the  XP  Cell  onboard  the  BLR  contributed  significantly  to  the 
level  of  success  achieved  by  the  Coalition  Initiative. 

While  an  appropriate  degree  of  system  level  training  was  provided  to  ANZAC  operators  the 
technical  difficulties  addressed  above  compromised  the  ability  to  do  unit  level  and  above 
training. 

The  absence  of  ‘a  priori’  standard  operating  procedures  (SOPs)  for  the  fires  coordination 
process,  together  with  the  continued  presence  and  efforts  to  resolve  ADOCS  integration  issues 
essentially  undermined  all  higher  level  training.  The  result  was  the  on-going  confusion 
experienced  by  the  Coalition  team  in  the  fires  coordination  process. 


5.2  TST  PROCESSES  INITIATIVE  RESULTS 
5.2.1  Pending  Tasks 

The  TST  C2  System  needs  to  explicitly  tell  operators  which  tasks  are  theirs  to  perform  and  their 
priority.  The  ADOCS  approach  of  one  big  table  for  MISSION  FIRES  COORDINATION  and 
one  big  table  for  the  JOINT  TIME  SENSITIVE  TARGETS  MISSIONS  is  not  well  engineered 
for  people  performing  required  tasks. 

•  JFMCC,  the  JFACC,  the  JFACC  TST  cell,  X-Ray  Papa,  and  others  need  to  distinguish 
which  targets  on  the  list  are  their  responsibility  and  which  are  someone  else’s. 

o  This  requires  them  to  scan  the  list  doing  mental  vertical  sorting. 

•  They  also  need  to  see  if  there  is  some  action  for  them  to  take. 

o  This  requires  them  to  scan  the  table  doing  mental  horizontal  sorting. 

•  They  have  no  list  of  pending  actions. 

•  There  is  no  prioritization  of  actions  waiting  to  be  perfonned. 

Tracks  or  tasks  are  implicitly  queued  up  waiting  for  action,  but  the  ADOCS  system  has  no 
explicit  queues  of  pending  actions.  If  one  thinks  of  tasks  (tracks)  as  waiting  for  service  by 
someone,  then  there  is  no  engineered  discipline  about  who  gets  served  next.  It  isn’t  even  fair  to 
say  that  the  next  target  to  be  served  is  random  (in  the  Monte  Carlo  sense).  It  appears  that  it  will 
vary  from  operator  to  operator  depending  on  how  an  operator’s  eyes  scan  the  table.  It  is  more 
haphazard  than  how  different  people  scan  their  e-mails  (most  people  routinely  approximate 
LIFO  or  FIFO  disciplines). 
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The  order  in  the  ADOCS  table  has  to  do  with  when  the  original  nomination  came  in.  There  is  no 
organization  based  on  actions  waiting  to  be  performed.  The  implication  of  this  observation,  is 
that  there  should  probably  be  explicit  lists  (queues)  of  waiting  actions,  and  a  requirement  for 
explicit  tools  or  windows  for  people  to  cycle  through  those  pending  actions  in  some  default  or 
operator-adjusted  prioritized  order. 


5.2.2  Human  Systems  Integration  for  Color-coding 

For  time-critical  tasks,  the  TST  C2  System  color-coding  should  be  standardized  and  intuitive  so 
that  operators  will  respond  predictably  and  quickly. 

Color-coding  is  critical  to  using  ADOCS  as  a  coordination  tool.  Operator  discussion  which 
color  means  what  quickly  degenerated  to 

•  “You  can  use  this  color  to  mean  this  if  it’s  in  this  block  entered  by  this  person,  but  it 
could  mean  that  in  that  block  if  entered  by  that  person.”  or 

•  “This  other  color  could  be  used  here,  and  that  color  could  be  used  there.” 

The  discussion  usually  reaches  a  climax  when  someone  says  that  a  color  can 

•  “mean  whatever  you  want.” 

Then  they  finally  sit  down  and  invent  a  color  scheme,  which  is  non-standard  because  there  are 
no  standards. 

This  isn’t  merely  a  training  or  doctrine  issue.  If  color-coding  is  being  used  for  coordination  of 
time-critical  tasks,  then  the  colors  or  symbols  used  should  be  engineered  to  be  much  more 
intuitive  than  they  are.  Ideally, 

•  as  intuitive  as  real  traffic  lights  so  that  people  will  respond  predictably,  and  quickly. 


5.2.3  Human  Systems  Integration  for  Symbol-coding 

For  time-critical  tasks,  the  TST  C2  System  use  of  symbol-coding  to  supplement  color-coding 
should  be  automated,  streamlined,  or  eliminated.  The  coding  scheme  developed  for  ADOCS 
blocks  includes  an  X  in  some  blocks  on  top  of  the  color.  This  scheme  now  requires  two 
distinctly  different  sets  of  actions,  one  to  set  the  color,  and  another  sequence  of  actions  to  add  the 
X  when  needed.  This  is  not  as  streamlined  and  error-resistant  as  a  TCT  process  should  be. 


5.2.4  Equipment  Casualty  Modes 

The  TST  C2  System  needs  to  have  reliable  alternative  modes  of  operation  and  more  graceful 
degradation  than  is  currently  available  with  open-architecture  LANs  and  internet-style  networks. 
When  the  Secret  LAN  wasn’t  available  and  there  was  no  ADOCS,  no  chat,  no  SIPRNET  e-mail, 
etc.,  one  of  the  reactions  was  to  discuss  and  explore  “what  are  our  work-arounds.” 

•  A  bigger  question  for  Network-centric  Warfare  and  FORCEnet  is  whether  or  not  casualty 
modes  will  be  engineered  into  the  architectures. 
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Most  legacy  combat  systems  have  casualty  modes.  Some  have  several  levels  of  casualty  modes. 
There  is  a  risk  that  the  down-time  and  network  problems  encountered  in  FBE-K  may  not  be 
atypical  of  what  might  occur  in  the  real  world  with  leading  edge  technologies,  pushing  the 
envelope,  built  on  open-architecture  machines  and  networks. 


5.2.5  Target  Prioritization 

The  TST  C2  System  needs  a  TST  prioritization  scheme  that  takes  into  account  both  the 
importance  of  the  target  and  the  amount  of  time  that  it  will  be  available  for  engagement.  There 
is  a  non-mandatory  block  in  ADOCS  for  target  priority.  Some  units  made  their  own  inputs  there. 
Most  didn’t. 

•  Procedures  are  needed  for  who  is  supposed  to  enter  a  priority. 

Most  important  are: 

•  What  does  the  priority  mean? 

•  How  is  it  to  be  detennined? 

There  are  static  priority  categories  listed  in  the  CJTF  TST  matrix,  but  those  numbers  don’t  take 
into  account 

•  the  amount  of  time  available  to  engage  the  target. 

There  are  available  simple  mathematical  models  (fonnulas)  for  prioritization  based  on  both 
target  utility  and  probability  that  it  will  remain  engageable  for  some  period  of  time  (one  simple 
approach  looks  like  economic  discounting).  Target  prioritization  needs  to  be  addressed  in  TST 
command  and  control. 


5.2.6  TSTs  that  move,  re-position,  and  change  status 

The  TST  C2  System  needs  functionality  for  automatically  and  unambiguously  keeping  track  of 
targets  that  move,  re-position,  and  change  status.  ADOCS  needs  functionality  added  for  targets 
that  may  move  (allowing  a  track  number  to  move  with  them  so  long  as  they  are  held  by  sensors), 
i.e.,  dynamic  target  position  infonnation  rather  than  static  data  fields.  Concurrently  functionality 
is  needed  for  automatic  updating  and  alerting  of  decision  makers  and  engagers.  This  shouldn’t 
rely  on  voice  or  chat  or  typed-in  remarks. 

ADOCS  functionality  is  also  needed  for  other  critical  changes  in  target  status,  such  as  missiles 
transitioning  from  stowed  to  erected  positions.  This  may  require  dynamic  updating  of  target 
description,  and  certainly  needs  automatic  updating  and  alerting  of  decision  makers  and 
engagers. 


5.2.7  Alternative  Approaches  to  Time  Sensitive  Command  and  Control 

Systems  engineering  of  a  TST  C2  System  should  look  beyond  the  extensive  typing  input-output 
approach  in  ADOCS,  and  its  matrix  displays,  for  TST  coordination  status.  It  became  apparent 
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during  FBE-K  that  many  of  the  C2  processes  in  ADOCS  are 

•  complicated, 

•  difficult  to  define  unambiguously, 

•  challenging  to  train  to,  and 

•  highly  dependent  on  internet  chat  and  voice  elaboration. 

It  is  understood  that  the  “development”  of  ADOCS  is  an  Advanced  Concept  Technology 
Demonstration  (ACTD).  Presumably,  the  ACTD  was  focused  on  whether  or  not  this  concept 
and  technology  can  be  applied  for  Army  artillery  deep  operations.  A  question  now  that  the 
technology  is  being  demonstrated  is: 

•  Is  it  is  the  right  concept  to  be  applied  to  Joint  Time  Sensitive  Targeting? 

Because  of  the  time-sensitivity  of  the  targets  and  because  it  is  at  the  tactical  level  of  war,  some 
of  the  functionality  built  into  air  defense  command  and  control  systems,  such  as  NTDS  or 
AEGIS  or  AWACS  should  be  examined  for  applicability  to  ground  TSTs. 

Besides  being  used  for  air  targets,  NTDS  and  AEGIS,  C2  systems  are  applied  very  effectively 
for  anti-submarine  command  and  control,  and  for  maritime  anti-surface  command  and  control. 
These  systems,  and  their  inherent  interoperability  with  AWACS,  Link  16,  (and  maybe  CEC), 
etc.,  should  be  examined  closely  for  functionalities  applicable  to  ground  TST  C2. 

No  matter  what  advances  are  made  in  internet  technology  (and  FORCEnet),  it  is  unimaginable 
that  anyone  would  ever  seriously  suggest  replacing  existing  Air  Defense  C2  systems  with 
internet  chat  and  convoluted  status  board  collaboration  as  currently  used  in  ADOCS. 

•  This  suggests  that  the  advantages  of  real-time  tactical  data  systems  should  considered  for 
other  tactical  time-sensitive  command  and  control  such  as  for  ground  TSTs. 

5.3  OBJECTIVE  DATA 
5.3.1  Data  Overview 

Compared  to  other  recent  FBEs  the  objective  data  provided  for  this  experiment  was  deficient  in 
quantity  and  quality.  In  particular: 

•  The  provided  TES-N  covered  only  a  few  days  of  the  CPX  and  was  reformatted  so  as  to 
be  unusable. 

•  No  GISRC  data  were  provided. 

•  The  ADOCS  JTST  manager  did  not  set  capture  mission  histories  for  the  last  two  days  of 
the  experiment 

•  After  acquiring  excellent  mensuration  data  from  RRF  in  FBE-J,  FBE-K  reverted  to  PTW 
which  has  never  provided  usable  data. 

•  The  JSAF  event  data  logged  in  SNN  did  not  include  Fire  events.  There  were  gaps  in  the 
JSAF  event  data  and/or  many  fire  commands  did  not  reach  JSAF. 

Among  the  factors  contributing  to  this  degraded  data  state: 
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•  The  teams  supporting  some  of  the  systems,  notably  ADOCS  and  GISRC,  were  new  to 
FBEs. 

•  More  systems  were  organic  to  operational  platforms. 

•  Integration  testing  ran  behind  schedule. 


5.3.2  ADOCS  Fires  and  JTST  Displays 

The  ADOCS  data  logs  were  collected  daily  and  provide  the  end-state  of  the  experiment  day’s 
Mission  Coordination:  Fires  (hereafter  Fires)  and  JTST  Manager  displays.  Table  1  below 
provides  the  number  of  nominations  as  a  function  of  the  nominator  for  the  last  several  days  of 
the  FTX.  The  experiment  day  ran  from  approximately  800  to  1800  Guam  time.  The  times 
reported  in  ADOCS  were  GMT.  The  missions  in  ADOCS  were  assigned  to  Guam  experiment 
day  X  if  the  time  the  mission  was  received  in  ADOCS  was  between  GMT  day  X-l  1400  hours 
and  GMT  day  X  1400  hours.  Most  missions  were  received  during  the  nominal  experimental  day 
but  some  nominations,  particularly  for  DD-X,  were  received  outside  these  hours.  The  data  in 
Table  1  were  derived  from  the  ADOCS  logs  from  the  Newport  ADOCS  server.  The  Newport 
server  data  were  not  captured  on  April  29.  Only  the  period  subsequent  to  April  27  is  addressed. 

Table  1.  ADOCS  Target  Nominations  from  the  Newport  ADOCS  Server 


Date 

Target  Nominations 

TOT 

AA 

AB 

AE 

AX 

GE 

GX 

TB 

XX 

5/2 

9 

9 

0 

27 

5 

18 

3 

0 

71 

5/1 

3 

31 

0 

1 

5 

23 

9 

4 

76 

4/30 

11 

15 

0 

22 

5 

20 

4 

2 

79 

4/29 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

4/28 

10 

10 

0 

0 

5 

0 

3 

11 

39 

TOT 

33 

65 

0 

50 

20 

61 

19 

17 

265 

Notes  to  Table  1: 

The  nominator  codes  appearing  in  Table  1  are  as  follows: 


AA 

ANZAC  ADOCS 

AB 

Blue  Ridge  ADOCS 

AE 

E-2C  ADOCS 

AX 

DD-X  ADOCS 

GE 

E-2C  GISRC 

GX 

DD-X  GISRC 

TB 

Blue  Ridge  TES-N 

XX 

Test 

Codes  are  used  as  prefixes  for  the  target  numbers  nominated  by  the  corresponding  nodes. 


Not  all  test  cases  were  distinguished  by  the  XX  prefix.  There  were  a  few  cases  where 
nominations  are  identified  as  tests  in  the  target  description  but  are  given  the  nonnal 
nominator  prefix.  These  cases  are  not  separated  out  in  the  above  table. 
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Table  2  presents  the  same  data  as  seen  in  data  logs  from  the  Blue  Ridge  ADOCS  server. 

•  The  expectation  is  that  Tables  1  and  2  would  show  the  same  results.  They  do  not. 

Table  3  shows  the  nomination  differences  between  the  Blue  Ridge  and  Newport  ADOCS  server 
logs  for  each  experiment  day  as  a  function  of  nominator.  In  a  few  cases,  one  of  the  logs  will 
inexplicably  contain  a  mission  from  a  previous  day.  In  principle,  the  discrepancies  could  also  be 
caused  if  one  of  the  ADOCS  servers  was  shut  down  prior  to  the  end  of  the  experiment  day.  But  a 
review  of  the  data  for  May  1  and  2  show  no  evidence  of  this.  Each  cell  in  Table  3  contains  the 
total  discrepancy  between  the  two  Newport  and  Blue  Ridge  ADOCS  listing  the  total  number  of 
nominations  that  appear  in  one  ADOCS  but  not  the  other,  rather  than  the  simple  difference  in  the 
counts  in  the  two  displays. 

The  impact  of  the  failure  of  all  target  nominations  to  appear  in  all  ADOCS  workstations  is 
illustrated  by  nomination  TB005 1  which  occurred  on  April  30.  This  mission  appears  in  both  the 
Blue  Ridge  and  ADOCS  servers  it  did  not  appear  in  the  E-2C  ADOCS  workstation  which  was 
being  tasked  by  the  TST  LNO  to  engage  the  target.  Communications  and  actions  relating  to  this 
nomination  are  found  in  Annex  B2. 


Table  2.  ADOCS  Target  Nominations  from  the  Blue  Ridge  ADOCS  Server 


Date 

Target  Nominations 

TOT 

AA 

AB 

AE 

AX 

GE 

GX 

TB 

XX 

5/2 

8 

14 

0 

27 

5 

17 

2 

0 

73 

5/1 

5 

37 

0 

1 

5 

24 

8 

3 

83 

4/30 

10 

15 

0 

12 

6 

12 

4 

2 

61 

4/29 

2 

17 

1 

6 

5 

6 

9 

0 

46 

4/28 

4 

10 

0 

0 

5 

0 

3 

20 

42 

TOT 

29 

93 

1 

46 

26 

59 

26 

25 

305 

Table  3.  The  difference  in  nominations  appearing  in  the  Blue  Ridge  and  Newport  ADOCS 


Date 

1 

farget  Nominators 

AA 

AB 

AX 

GE 

GX 

TB 

5/2 

1 

8 

0 

0 

1 

1 

5/1 

3 

8 

0 

0 

1 

2 

4/30 

1 

0 

10 

1 

8 

0 

4/29 

NA 

NA 

NA 

NA 

NA 

NA 

4/28 

6 

2 

0 

0 

NA 

0 

The  ADOCS  Fires  Manager  is  the  tool  for  engagement  prosecution.  The  ADOCS  Joint  Time 
Sensitive  Target  (JTST)  Manager  is  the  tool  for  cross  Component  TST  coordination.  Only  the 
Blue  Ridge  ADOCS  server  displayed  and  logged  the  JTST  Manager  data  (All  the  Component 
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inputs  were  simulated  in  various  cells  on  the  Blue  Ridge). 


Table  4  compares  the  data  from  the  Fires  and  JTST  Managers.  The  number  of  target  nomination 
appearing  in  the  JTST  Manager  is  many  fewer  than  appears  in  the  Fires  Manager  This  is  not 
unexpected  since  non-TST  targets  should  not  be  promoted  to  the  JSTS.  Other  differences  are  of 
more  concern.  In  particular,  some  targets  appear  in  JTST  but  not  in  Fires  (e.g.  TB  0060  on  1 
May  and  TB  0063  on  May  2).  Another  problem  is  that  the  status  of  engaged  targets  that  appear 
in  both  tables  is  not  the  same  (e.g.,  on  May  1  Both  TB0062  and  TB0058  are  shown  as  engaged  in 
Fires  but  only  TB0058  is  shown  as  engaged  in  JTST). 

Table  4.  Comparison  of  Mission  Coordination:  Fires  and  JTST 


Notes  to  Table  4: 

(1) Column  N  gives  the  number  of  target  nominations 

(2) Column  F  gives  the  number  of  missions  where  the  target  was  engaged. 

(3) Fires  engagement  is  defined  as  having  the  FRD  block  green 

(4) JTST  engagement  is  defined  as  having  the  MSN  block  green.  EXE  is  almost  always 
also  displayed  in  the  block. 

(5) The  data  in  the  F  column  for  JTST  is  presented  in  the  form  2/1.  The  first  number 
indicates  the  number  of  MSN  blocks  that  are  green  and  contain  the  characters  EXE.  The 
second  number  indicates  the  number  of  MSN  blocks  that  contain  EXE  but  are  yellow. 

(6) The  interpretation  of  the  second  number  is  unclear.  Where  only  a  single  number 
appears  all  the  fired  missions  were  Green  with  EXE. 

(7) Some  inconsistencies  between  the  number  of  missions  fired  in  Fires  and  JTST  are 
indicated  by  bold  typeface. 

It  is  concluded  there  are  significant  inconsistencies  in  the  ADOCS  Fires  displays  in  different 
servers  and  significant  inconsistencies  between  the  Fires  and  JTST  Manager  displays.  As  a 
result  of  these  inconsistencies  ADOCS  fails  to  provide  an  unambiguous  common  operational 
picture. 
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5.3.3  Target  Handoffs. 


From  the  last  four  days  of  the  FTX  the  table  below  presents,  for  each  nominator,  the  number  of 
nominations  that  were  paired  to  a  lirer,  as  indicated  in  the  Blue  Ridge  ADOCS,  and  which  firer 
they  were  paired  with.  The  last  column  provides  the  percent  of  the  cases  where  the  paired 
shooter  was  the  same  as  the  nominator.  Where  the  nominator  had  an  engagement  capability,  the 
mission  nominator  was  also  the  shooter  in  71  to  100  percent  of  the  cases;  relatively  few 
nominations  were  passed  to  another  shooter  for  execution.  There  was  limited  collaboration 
among  the  engagement  platforms.  The  DD-X  in  particular  (nomination  prefixes  AX  and  GX), 
engaged  virtually  all  the  targets  it  nominated.  The  nominations  originating  on  the  Blue  Ridge 
(nomination  prefixes  AB  and  TB)  had  to  be  passed  to  other  platforms  for  engagement  since  the 
Blue  Ridge  had  no  engagement  capability.  The  GISRC  on  the  vANZAC  perfonned  no  target 
nominations  or  at  least  none  that  reached  the  FBE  net  ADOCS. 

Table  5.  4/29  to  5/2  BLR  ADOCS  Data.  Number  of  nominations  that  were  Weapon-Target 
paired  and  the  number  that  were  paired  with  the  nominator  as  a  function  of  nominator. 


Nominator 

#Noms 

#  Noms 
paired 

% 

paired 

Paired  platforms 

%  paired  with 
nominator 

DAH 

ANZ 

E2 

AA 

25 

14 

56 

2 

10 

2 

71 

AB 

79 

52 

66 

30 

18 

4 

0 

AX 

46 

43 

93 

43 

0 

0 

100 

AE 

1 

0 

0 

0 

0 

0 

NA 

GE 

20 

11 

55 

2 

0 

9 

82 

GX 

60 

45 

75 

43 

1 

1 

96 

TB 

26 

11 

42 

6 

1 

4 

0 

5.3.4  Mensuration. 

In  FBE-K,  the  messages  used  to  request  target  mensuration  and  to  report  the  georefinement 
results  used  in  other  FBEs  were  not  employed.  The  pre  experiment  mensuration  procedure  was  a 
chat  request  for  mensuration  to  PTW  and  for  the  PTW  operator  to  enter  the  georefinement  result 
directly  into  the  Electronic  Target  Folder  (ETF).  There  was  a  IRC  comment  by  the  PTW 
operator  that  he  was  not  connected  to  the  web,  hence  he  could  not  insert  the  results  into  the  ETF. 
In  practice,  mensuration  was  seldom  performed  as  result  attributable,  in  part,  to  the  poor  quality 
of  some  of  the  imagery  and  in  the  difficulties  in  transmitting  imagery  to  PTW.  It  is  the  case  that 
there  is  not  a  single  instance,  for  the  interval  28  April  to  2  May,  where  the  Georefinement  block 
in  the  ADOCS  Fires  Manager  indicates  that  georefinement  data  was  provided  for  a  target. 

The  TST  GEO  REF  IRC  channel  was  unused  for  the  duration  of  the  experiment 

Georefinement  was  not  a  consideration  in  the  engagement  process  in  this  experiment. 
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5.3.5  Rapid  Planning  Mode  (RPM) 


RPM  is  a  system  used  to,  on  request,  compute  the  routes  for  TLAM  missions.  The  data  collected 
from  this  system  have  been  used  to  compute  the  intervals  between  receipt  of  the  mission  request 
and  the  start  of  the  route  computation  ,  the  interval  required  for  then  actual  route  computation, 
and  the  interval  between  the  completion  of  the  route  computation  and  the  transmission  of  the 
route  result.  These  intervals  are  shown  in  Table  6  where  are  compared  with  the  results  from 
FBE-I.  The  data  for  FBE-K  include  only  the  interval  April  28  to  May  2.  In  both  cases  only  GO 
results  are  included.  The  much  longer  interval  in  which  the  route  are  waiting  attention  and  the 
much  faster  computing  time  in  FBE-K  are  notable.  The  following  explanation  of  these 
differences  was  provided  by  Dan  Turpin  of  Boeing. 

In  FBE-K  the  new  PC-based  RPM  was  used.  The  FBE-I  system  was  a  UNIX-based 
implementation.  On  that  system,  the  SMTP  (E-mail)  server  delivered  E-mail  to  the  waiting 
client  immediately  upon  receipt.  On  the  PC  implementation,  used  for  FBE-K,  there  is  a  polling 
interval  which  has  a  minimum  setting  of  one  minute.  In  the  PC  implementation,  Microsoft 
products  are  relied  on  to  handle  the  E-mail  interface,  while  on  the  UNIX  side  Boeing 
implemented  their  own  interface  to  the  HP-UX  SMTP  server.  The  timing  infonnation  reported 
when  a  request  was  received  on  UNIX  is  truly  the  time  the  local  SMTP  server  received  the 
message  and  notified  the  waiting  RPM  client.  On  the  PC  side,  it  looks  like  the  time  is  generated 
by  the  Exchange  server,  external  to  the  local  Outlook  Express  client  on  the  RPM  machine.  It 
appears  that  the  receipt  time  on  the  PC  version  is  probably  set  earlier  than  when  the  message  is 
actually  received  by  the  RPM  software.  The  timing  information  for  message  receipt  to  the  start 
of  processing  is  really  difficult  to  compare  between  the  two  implementations.  For  the  route 
computation  time,  that's  a  function  of  processor  speed.  The  old  HP  UNIX  systems  were  running 
around  100  MHz  while  the  PC  systems  were  somewhere  in  the  1.2GHz  range. 

Table  6.  A  comparison  of  RPM  Processing  times  from  FBE-K  and  FBE-I 

(Times  are  medians  and  in  seconds) 


Experiment 

Intervals 

Sample 

size 

Request 
receipt  to  start 
computation 

route 

computation 

Complete 
computation 
to  send  result 

Total: 
receipt  to 
send 

FBE-K 

251 

17 

5 

277 

116 

FBE-I 

4 

71 

2 

79 

75 

66 


5.4 


ENGAGMENT  TIMELINES 


5.4.1  TST  TTP 

The  significance  of  the  colors  in  the  ADOCS  coordination  blocks  and  the  agent  that  controls  the 
status  of  the  blocks  is  routinely  a  problematic  issue  in  FBEs.  FBE-K  was  no  exception.  Table  7 
presents  the  instructions  distributed  to  participants  for  the  ADOCS  Mission  Coordination:  Fires 
Manager.  Following  that,  in  Table  8,  is  an  excerpt  taken  from  the  ANZAC  OPS  IRC  channel 
on  April  30.  In  this,  XP  ANZAC  defines  the  methodology  to  be  used  for  color  changes  in  the 
ADOCS  Mission  Coordination:  Fires  XPA  and  ANZ  coordination  blocks.  The  two  procedures 
described  in  Tables  7  and  8  are  not  the  same.  For  example,  Table  7  indicates  the  ANZ  going 
yellow  shows  the  ANZAC  is  ready  to  engage.  Table  8  states  the  ANZ  going  yellow  indicates  the 
assignment  of  the  target  to  ANZAC  by  XP.  This  no  doubt  contributed  to  participant  confusion 
regarding  ADOCS  TTP  procedures.  That  confusion  is  well  illustrated  by  an  excerpt  from  the 
AIR  OPS  IRC  channel  of  a  conversation  that  occurred  on  April  30  (see  Appendix  A). 

In  the  examination  of  individual  engagement  timelines  where  there  is  a  conflict  between  the 
procedures  defined  in  Tables  7  and  8,  the  latter  is  taken  as  the  standard. 

Table  7.  FBE-K  ADOCS  Mission  Coordination  Fires  Approval  Block  Color  Codes 


Mission  Coordination:  Fires  -  Active  Missions 


Tab 

Tab  Definition 

Responsible  Party 

Color 

Definition 

TCT 

Time  Sensitive  Target 
determination 

XP 

= 

Yellow 

Possible  TST,  Begin  Strike  Planning 

Red 

Not  a  TST 

Green 

Confirmed  TST/PID 

XPA 

Experimental  Strike  Warfare 
Commander 

XP 

Yellow 

Strike  approval  received 

Blue 

Acknowledged 

Green 

Cleared  to  engage  (w/  green  range) 

Red 

Abort 

E2X 

Virtual  vE2X  Mission  Assignment 
Coordination 

E2X 

Blue 

Acknowledged 

Yellow 

Ready  to  engage 

Green 

Shooter  cleared  to  fire 

Red 

Unable  to  execute 

White 

No  Mission  assigned 

DDX 

Virtual  vDDX  Mission  Assignment 
Coordination 

DDX 

Blue 

Acknowledged 

Yellow 

Ready  to  engage 

Green 

Shooter  cleared  to  fire 

Red 

Unable  to  execute 

White 

No  Mission  assigned 

ANZAC 

Virtual  ANZAC  Mission  Assignment 
Coordination 

ANZAC 

Blue 

Acknowledged 

Yellow 

Ready  to  engage 

= 

Green 

Shooter  cleared  to  fire 

Red 

Unable  to  execute 

White 

No  Mission  assigned 

ADC 

Air  Defense  Commander 

XP/TCT 

Red 

Pending  De-confliction 

Green 

De-confliction  Complete 

JIC 

Joint  Intelligence  Center 

JIC 

Yellow 

E 

Green 

Red 

White 
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Table  8.  ADOCS  Missions  Coordination:  Fires  TST  TTP  (Chat  Excerpt) 

[00:07]  <XP_ANZAC>  1.  XP  acknowledged  and  working  mission  -  XP  turns  XPA  tab 
yellow. 

[00:07]  <XP_ANZAC>  2.  XP  assigns  mission  to  vANZAC  -  XP  turns  ANZ  tab  yellow 
[00:07]  <XP_ANZAC>  3.  VANZAC  acknowledges  mission  -  XP  ANZAC  turns  ANZ  tab 
blue  once  acknowledgement  received  via  chat  from  CO  ANZAC. 

[00:07]  <XP_ANZAC>  4.  VANZAC  accepts  mission  -  XP  ANZAC  turns  ANZ  tab  green 
once  mission  is  accepted  via  chat  from  CO  ANZAC. 

[00:07]  <XP_ANZAC>  5.  XP  acknowledges  mission  acceptance  -  XP  ANZAC  turns  XPA  tab 
blue. 

[00:07]  <XP_ANZAC>  6.  XP  authorizes  engagement  -  XP  turns  XPA  tab  green 
[00:07]  <XP_ANZAC>  7.  CO  ANZAC  engages. 

[00:09]  <XP_ANZAC>  This  is  current  procedure  for  us. 

[00:09]  <CO_ANZAC>  rgr-copy.  We  will  pass  to  AUS 

The  headings  of  the  coordination  blocks  in  the  post  trial  reconstructed  ADOCS  Fires  displays  are 
the  same  as  those  used  in  FBE-J  and  are  not  those  used  in  FBE-K.  The  correspondence  between 
the  headings  is  shown  in  columns  1  and  2  of  Table  9.  In  the  Mission  History  files,  a  completely 
different  set  of  names  are  used  when  referring  to  coordination  block  actions.  The 
correspondence  between  those  names  and  those  used  in  the  ADOCS  Fires  display  is  given  in  the 
third  column  of  Table  9. 

Table  9.  Correspondence  between  the  Multiple  names  applied  to  the 
ADOCS  Mission  Coordination:  Fires  Coordination  Blocks 


Post  Trial  Display 

FBE-K 

Mission  History 

MCC 

TCT 

TGT 

STW 

XPA 

OPS 

see 

E2X 

AIR 

MIW 

DDX 

OPT1 

IWC 

ANZ 

OPT2 

ADC 

ADC 

OPT3 

AWC 

JIC 

OPT4 

5.4.2  TTP  Issues 

Appendix  A  contains  event  timelines  for  several  target  nominations.  Detailed  examination  of  the 
engagement  timeline  events  provides  objective  information  on  the  TST  TTP  actually  used  and  an 
assessment  of  the  systems  employed  in  prosecuting  the  targets.  All  the  timelines  include  operator 
actions  extracted  from  the  ADOCS  Mission  History  logs  and  participant  conversations  excerpted 
from  multiple  IRC  channels.  Where  pertinent,  data  are  also  taken  from  RPM  and  SNN  which 
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respectively  contain  TLAM  route  generation  events  and  JSAF  engagement  information.  General 
conclusions  from  a  review  of  these  timelines  are  presented  below. 


ADOCS  Coordination  Block  Actions 

The  actions  of  the  ADOCS  workstation  operators  in  changing  the  colors  of  the  coordination 
blocks  illustrate  many  departures  from  the  published  TTPs.  A  primary  cause  for  this  was  the 
participant  confusion  regarding  the  TST  TTP.  Such  confusion  has  been  a  chronic  ADOCS 
problem  in  FBEs.  Another  factor  contributing  to  these  departures  is  latencies  and 
inconsistencies  in  the  ADOCS  displays  (see  Section  5.2.2) 

The  types  of  departures,  in  ADOCS,  from  the  TTP  include: 

a.  Required  TTP  actions  not  taken. 

b.  Actions  taken  but  not  by  the  responsible  node. 

c.  Actions  taken  that  are  undefined  by  the  TTP  and  hence  meaningless. 

d.  Actions  executed  in  the  wrong  sequence. 

e.  Actions  executed  in  such  a  way  as  to  indicate  that  the  actions  were  taken  to  force  the 
engagement  to  a  conclusion  rather  than  as  a  result  of  a  realistic  response  to  the  simulated 
engagement. 

Table  10  shows,  for  the  five  timelines  examined  from  late  in  the  FTX,  the  correspondence 
between  required  coordination  block  actions  (as  defined  by  Tables  7and  8)  and  what  actually 
occurred. 

Table  10,  Mission  Conformance  to  TTP 


Actio 

Target  Nomination 

TB0050 

TB0051 

AB5027 

GX0321 

AA0368 

TCT  yellow  (begin  strike  planning) 

N 

Y 

N 

N 

Y 

TCT  green/red  (  yes/no  TST) 

N 

Y 

N 

Y  (4) 

Y 

Promote  to  JTST 

Y 

Y 

N 

Y 

Y 

ADC  red  (deconflicting) 

Y 

N 

N 

Y 

Y 

ADC  green  (deconfliction  complete) 

Y 

Y 

N 

N 

Y 

XPA  yellow  (working  mission) 

Y 

Y 

Y(l) 

Y 

Y 

Shooter  yellow  (assigned  mission) 

Y 

Y 

Y  (1) 

Y 

N 

Shooter  blue  (ack  assignment) 

Y 

N 

Y(2) 

Y(3) 

N 

Shooter  green  (accept  mission) 

Y 

N 

Y  (3) 

Y(3) 

Y 

XPA  blue  (ack  acceptance) 

Y 

N 

Y 

Y 

N 

XPA  green  (authorize  engagement) 

Y 

N 

Y 

Y 

Y 

FRD  green  (weapon  fired) 

Y 

N 

Y 

Y 

Y 
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Notes  to  Table  10: 

(1) .  These  events  appear  in  the  wrong  sequence. 

(2) .  This  is  IRC  statement  from  ANZAC  that  they  turned  the  ANZ  block  blue  in  their 
display.  This  does  not  appear  in  the  FBE  net  ADOCS. 

(3)  This  action  was  taken  by  BLR  on  behalf  of  ANZAC. 

(4)  Action  out  of  sequence.  The  target  was  not  confirmed  as  TST  until  after  the 
engagement  was  completed. 

ANZAC  ADOCS  Coordination  Block  Actions 

In  the  BLR  ADOCS  Mission  History  no  actions  were  reported  as  executed  by  ANZAC.  All  those 
actions  which  should  have  been  executed  by  ANZAC  were  carried  out  on  the  BLR  The  IRC  chat 
shows  that  the  ANZAC  was  executing  the  required  actions  (e.g.,  see  mission  AB5027  Annex  B3) 
but  it  appears  that  these  events  were  not  making  it  through  Radiant  Mercury  to  the  FBE  net.  The 
ADOCS  TTP  promulgated  on  May  1  (see  Table  8)  has  the  BLR  entering  into  ADOCS  the 
required  ANZAC  actions  on  receiving  the  IRC  communications  requesting  those  actions  from 
the  ANZAC.  It  is  presumed  this  TTP  was  created  to  circumvent  Radiant  Mercury. 

Redundancy  of  IRC  and  ADOCS 

The  event  timeline  IRC  entries  sometimes  show  detailed  reporting  regarding  the  color  block 
changes  that  are  being  made  to  the  ADOCS  display  (e.g.,  see  AB  5027).  This  is  attributable,  in 
part,  to  uncertainty  among  some  participants  about  the  TST  procedures  and,  in  part,  to  the  lack 
of  confidence  in  ADOCS  to  accurately  reflect,  in  a  timely  manner,  the  operator  block  actions  to 
all  ADOCS  workstations.  These  detailed  communications  result  in  an  expansion  of  the 
engagement  timeline  and,  in  effect,  make  ADOCS  redundant  -  all  the  coordination  actions 
appear  to  be  occurring  in  chat  and  ADOCS  becomes  unnecessary. 


5.4.3  ADOCS  issues 

Latencies  and  Inconsistencies 

Latencies  and/or  inconsistencies  in  the  ADOCS  information  are  common.  Such  ADOCS 
latencies/inconsistencies  have  been  a  recurrent  problem  in  FBEs.  Specific  problems  revealed  in 
the  development  of  engagement  timelines  include: 

a.  Missions  appear  in  some  ADOCS  workstations  but  not  others. 

b.  The  coordination  block  status  can  be  different  at  different  ADOCS  workstations. 

c.  The  mission  status  (e.g.  fired  or  not  fired)  may  be  different  in  the  Mission  Coordination: 
Fires  and  JTST  Managers.  For  the  JFMCC/XP  ADOCS  Mission  Coordination:  Fires 
Manager  is  the  primary  tool  for  prosecution  of  TSTs.  The  JTST  Manager  is  a 
collaboration  tool  to  provide  TST  situational  awareness  to  all  Components. 

d.  The  Mission  Coordination:  Fires  and  JTST  Mission  Histories  can  be  inconsistent. 
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e.  Mission  status  as  detennined  from  the  Mission  History  may  not  agree  with  the  status  in 
the  Mission  Coordination:  Fires  display 

f.  Some  events  are  missing  from  the  Mission  Histories. 

g.  There  are  multiple  examples  in  the  Mission  History  of  blocks  being  changed  from  colors 
that  they  do  not  hold.  For  example  mission  GX023 1,  at  3: 15  XPA  changed  from  white  to 
blue  (by  BLR  SPARE  4  ADOCS  workstation).  The  next  recorded  action  for  that  block 
shows  it  being  changed  at  3: 18  from  white  to  yellow  (by  the  BLR  JOC  STATION  3). 
There  are  two  possible  explanations  for  this:  there  is  an  event  changing  the  block  from 
blue  to  white  missing  from  the  Mission  History  log  or  the  change  at  3: 15  was  not 
received  by  the  second  workstation  so  in  his  context  the  block  was  still  white  . 

Specific  examples  and  details  of  these  problems  are  highlighted  in  the  examination  of  mission 
timelines  in  Appendix  A. 

ADOCS  is  the  core  tool  for  TST  engagement  and  target  management.  If  this  tool  does  not 
provide  timely  reliable  and  consistent  information  the  engagement  process,  at  the  least,  will  be 
degraded  in  terms  of  timely  and  accurate  delivery  of  ordinance  to  the  target,  at  worst  the 
engagement  will  not  be  executed  at  all.  These  inconsistencies  also  make  it  difficult  to 
reconstruct  and  evaluate  what  actually  occurred. 

Radiant  Mercury 

ANZAC  reported  Fires  mission  manager  for  ANZ  tab  resets  to  white  for  every  Radiant  Mercury 
Guard  (RMG)  transmission.  The  work  around  was  for  BLR  ADOCS  operator  to  edit  ADOCS 
tabs  on  behalf  of  ANZAC. 


5.4.4  Other  issues 

System  Clock  Synchronization 

System  clocks  were  not  synchronized.  The  time  stamps  applied  to  the  ADOCS  Blue  Ridge  logs 
are  about  4  minutes  different  from  the  time  stamps  applied  to  IRC  logs. 

Target  Position  Georefinement 

There  is  no  indication  for  any  of  the  reviewed  engagements  that  target  georefinement  was 
performed. 

IRC  Nets 

Because  the  FBE  net  and  Coalition  net  are  not  connected,  IRC  communications  must  be 
manually  transferred  from  one  net  to  the  other.  Typically  there  was  about  a  seven  minute 
interval  between  the  appearance  of  a  message  in  the  two  IRC  nets. 
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5.5  ISR  AND  JFN  OBSERVATIONS 


These  results  are  extracted  from  Appendix  D.  For  a  complete  description  of  ISR  and  JFN 
observations  from  the  viewpoint  of  operations  within  the  JIC,  see  that  appendix.  Those  deemed 
to  have  had  the  most  significant  impact  on  achieving  the  Fires  Initiatives  objectives  are  discussed 
here.  The  observations  are  in  categories  and  presented  as  paired  observation-recommendation. 


5.5.1  FBE  Planning,  Organization,  and  Execution 

Continuity  Between  Concept  Development  and  Experiment  Implementation 

Observation :  A  lack  of  continuity  existed  between  the  development  of  FBE-K 
concepts/initiatives  involving  ISR/JFN,  and  the  actual  FBE-K  planning/implementation.  Among 
other  things,  this  discontinuity  hampered  the  development  of  meaningful  analytic  questions,  and 
the  experimental  techniques  to  help  answer  those  questions. 

Recommendation :  Those  involved  in  the  development  of  experimental  concepts  and 
initiatives  must  remain  fully  engaged  throughout  the  FBE  planning  process,  if  not  also  during  the 
execution  and  after-action  analysis,  to  ensure  the  FBE  is  properly  focused  on  addressing  the 
original  intent  of  those  concepts  and  initiatives. 

Staff  Participation;  Fleet  Training  vs.  Experimentation 

Observation ;  From  the  ISR  perspective,  FBE-K  degenerated  almost  completely  into  a 
JFN  systems  training  event,  largely  because  participation  by  C7F  Staff  and  Fleet  forces  in  the 
planning,  preparation,  and  execution  was  constrained  to  such  an  extent  as  to  preclude  meaningful 
ISR  and  JFN-related  experimentation. 

Recommendation ;  Ensure  ISR  and  JFN  related  experimentation  involving  a  Numbered 
Fleet  has  full  buy-in  and  participation  of  that  Numbered  Fleet  staff,  particularly  the  operations 
(N3)  staff.  Be  prepared  to  postpone  or  cancel  experimentation  events  that  are  dependent  on 
Numbered  Fleet  staff  participation  as  soon  as  it  becomes  obvious  that  the  bulk  of  that  staffs 
focus  will  and  should  be  elsewhere  other  than  on  experimentation.  And  focus  experiments  on 
experimentation,  and  not  on  Fleet  training  /  exercises. 

NWDC  Division  of  Labor  and  FBE  “Supporting  Services” 

Observation:  FBE-K  experienced  some  of  the  same  difficulties  with  intra-NWDC 
organizational  challenges  and  “division  of  labor”  issues  as  past  FBEs.  While  these  were 
decidedly  not  “showstoppers”  in  FBE-K,  future  FBE  planning  and  execution  could  be 
significantly  enhanced  by  their  rectification. 

Recommendation :  Provide  greater  clarity  on  intra-NWDC  “division  of  labor”  for  all  the 
various  aspects  of  FBE  planning  and  execution.  Explicitly  identify  “supporting  services”  (such 
as  information/knowledge  management  and  COP/database  maintenance)  that  are  above  the 
strictly  technical  level,  but  are  distinct  from  any  “supported”  functional/experimental  initiatives. 
Assign  appropriate  roles,  responsibilities,  and  resources  to  address  each  of  these  services. 


Document  Control 
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Observation :  Like  most  previous  FBEs,  FBE-K  suffered  from  a  lack  of  document  control 
for  most  of  the  key  coordinating  documents. 

Recommendation :  Early  in  the  FBE  planning  stages,  identify  key  coordinating 
documents  (and  their  owners),  and  implement  an  FBE-wide  common  methodology  for  the 
cooperative  production,  review,  maintenance  and  accessibility  of  those  documents  —  while  at  the 
same  time  keeping  this  “FBE  document  control”  methodology  /  system  as  accessible,  flexible, 
and  non-burdensome  as  possible. 

Live  Forces,  ISR  Assets,  OPFOR,  Emitters,  and  Fires 

Observation :  As  advanced  as  today’s  M&S  is,  it  is  no  substitute  for  the  incorporation  of 
live  forces  and  live  operations  into  Fleet  Battle  Experiments. 

Recommendation-.  Conduct  all  future  ISR,  targeting,  and  JFN-related  experimentation 
with  as  many  live  forces  (including  live  OPFOR)  as  possible  to  increase  the  fidelity  of  the 
experiment  to  a  level  that  includes  as  many  of  the  “truly  hard”  analytic  processes  as  possible. 


5.5.2  Technology  and  Systems 

Operational  Sequence  Diagrams 

Observation :  Functional  Flow  Diagrams  (FFDs)  should  be  developed  prior  to  (or  in 
conjunction  with)  Operational  Sequence  Diagrams  (OSDs). 

Recommendation-.  For  subsequent  FBEs  (and  other  experimentation  events),  FFDs 
should  be  institutionalized  as  required  documents  for  all  initiatives,  to  describe  who  at  which 
functional  nodes  need  (or  will  provide)  what  information  from  (to)  whom  and  why.  The  OSDs 
should  subsequently  (or  concurrently)  be  developed  as  the  technical  reflection  of  those  FFDs. 

Common  Operational  Picture  (COP) 

Observation-.  The  COP  in  FBE-K  did  not  have  explicit  “ownership”  by  any  initiative, 
and  was  not  maintained  to  a  level  required  to  support  ISR  and  JFN  in  support  of  TST. 

Recommendation-.  Early  in  the  FBE  planning  stages,  identify  who  has  responsibility  for 
each  of  the  many  complex,  interdependent  functions  that  go  into  producing  an  accurate,  stable 
COP  from  which  players  will  be  capable  of  “fighting  the  experiment”  (instead  of  fighting  with 
the  COP).  Consider  doing  the  same  with  other  “foundational”  FBE  processes,  depending  on  the 
nature  of  the  experiment. 

Tactical  Exploitation  System  -  Navy 

Observation :  FBE-K  reconfirmed  that  TES-N  has  a  number  of  powerful  tools  (some  of 
which  are  unique  to  TES-N)  that  potentially  could  be  of  great  use  to  Naval  forces  involved  in 
Time  Sensitive  Targeting  (TST).  Unfortunately,  FBE-K  also  reconfirmed  that  TES-N  remains  a 
very  complex  and  developmentally  immature  system,  with  extremely  limited  interfaces  to  other 
C4I  systems  that  are  critical  to  TST,  in  particular  GCCS-M  and  ADOCS. 

Recommendation-.  Don’t  use  TES-N  in  any  further  TST-related  experimentation  until 
major  advances  are  made  to  at  least  the  following:  (1)  interface  with  ADOCS;  (2)  interface  with 
GCCS-M;  (3)  interface  to  PTW  and  any  external  target  folder  applications  (e.g.,  attachment  of 
image  chips  to  ATI.ATR  messages);  (4)  handling  of  ISR  video  and  platform/sensor  telemetry; 
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and,  (5)  SCI  COMINT  analysis  tools,  and  SCI-to-GENSER  connectivity  via  ISSE  Guard. 


5.6  TECHNICAL  RESULTS 

These  results  are  extracted  from  Appendix  C.  They  provide  a  more  complete  description  of 
technology  issues  than  presented  in  the  former  section.  For  a  complete  description  of  technical 
impacts  on  the  experiment,  see  Appendix  C.  Those  deemed  to  have  had  the  most  significant 
impact  on  achieving  the  Fires  Initiatives  objectives  are  discussed  here. 


5.6.1  Summary 

•  In-depth  insight  was  gained  into  many  JFN  systems  issues,  myths  and  realities.  It  was 
learned  once  again  that  TES-N  is  a  complex  and  developmentally  immature  system 
whose  strength/weakness  are  directly  related  to  the  strengths/weaknesses  of  its  interfaces 
with  communications,  with  other  JFN  systems,  and  with  ADOCS. 

o  Getting  TES-N,  the  rest  of  the  JFN  equipment,  and  its  many  intricate  interfaces  to 
really  full  mission  capability  requires  the  regular  (daily?)  attention  of  a  wide 
range  of  cooperating  technicians  and  system  operators,  both  on  board  and  off 
board. 

o  Operational  testing,  using  scripted  scenarios  (if  not  live  downlink  events)  forces 
issues  to  surface  that  would  not  appear  in  system  demonstrations  or  static  testing. 

•  Remote  M&S  stimulation  of  TES-N  /  JFN  was  sufficient  for  familiarizing  C7F  Staff  with 
the  basic  processes  involved  in  using  TES-N  /  JFN  in  support  of  TST  but  not  for  true 
training  or  experimentation. 

o  Continue  to  improve  quality  of  M&S  video  and  imagery  (e.g.,  1 -meter  base),  and 
platform  /  sensor  /  feed  characteristics  (particularly  simulation  of  U-2  products). 

•  TST  Target  Folder  server  concept  as  a  common  repository  for  relevant  TST  target  data 
was  successfully  demonstrated. 

o  Continue  attempts  to  incorporate  program-of-record  digital  target  folder  solution 
(e.g.,  Joint  Targeting  Toolbox,  based  on  MIDB)  into  future  ISR  /  TST 
experimentation  events. 

•  Several  planning  issues  impacted  the  quality  of  the  experiment.  Recommendations  for 
improvement  are: 

o  Thoroughly  test  TES-N  to  ADOCS  target  nomination  interface  prior  to  event 
STARTEX,  including  a  close  examination  of  how  individual  data  fields  are 
handled  through  the  whole  process. 

o  Clarify  division  of  labor  (and  increase  frequency  of  joint  planning  sessions) 
between  functional  leads,  IKA  team,  and  the  technical  team 

o  Assign  COP  ownership  and  explicitly  state  roles  and  responsibilities  (of  above 
three,  plus  players) 
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o  Produce  “Functional  Flow  Diagrams”  (FFDs?)  before  technical-level  OSDs, 
o  Provide  FBE-wide  document  responsibilities,  control,  and  distribution. 


5.6.2  M&S  Feeds  Into  TES-N 

Video:  During  both  CPX  and  FTX,  simulated  1SR  video  was  produced  by  AFSERS-MUSE,  fed  into  the 
NWDC  video  controller  in  Newport,  distributed  as  MPEG-4  to  BLR  via  the  FBE  WAN  (including 
KuBand  SATCOM).  The  MPEG-4  stream  was  converted  and  fed  by  the  NWDC  video  remote  server  on 
BLR  as  analog  video  (RS-170)  into  TES-N’s  video  switch,  which  then  presumably  re-digitized  the  video 
for  distribution  to  any  GENSER-level  TES-N  Multi-Function  Workstation 

•  The  video  feed  into  TES-N  was  stable  and  reliable  aside  from  BLR  video  remote  server’s 
display  need  for  re-set. 

•  Simulated  ISR  Video  C2  allowed  rapid  response  to  changes  in  circumstances  and/or  FBE 
participant  requirements. 

•  Some  confusion  over  who  had  C2  over  which  simulated  ISR  video  asset  demonstrated 
the  need  for  a  well-established  C2  structure  for  ISR  operations. 

•  Coordinate  with  ISR  “pilots”  via  voice-only  proved  unwieldy  due  to  lack  of  a 
workstation  IP  Chat  capability. 

•  After  an  A-to-D  conversion  or  two,  the  video  displayed  on  the  TES-N  MFWS  was  barely 
useable  for  TST  detection  and  identification. 

•  Video  image  “chips”  captured  by  TES-N  were  of  significantly  lower  quality  than  those 
captured  from  the  same  source  by  the  GISRC  workstations  at  Newport  and  Dahlgren. 

•  The  quality  of  the  simulated  video  would  not  be  sufficient  for  any  type  of  targeting 
experimentation  beyond  just  going  through  the  process  motions. 

o  When  zoomed  in  close  enough  to  support  positive  identification  (PID)  of  the  TST, 
the  background  of  base  imagery  became  so  blurred  as  to  appear  solid,  thereby 
losing  all  visual  context. 

o  The  combination  of  low  resolution  and  the  lack  of  features  that  are  easily 

identified  at  coarse  image  resolution  prevented  visual-point-transfer  between  the 
video  images  and  the  Digital  Point  Positioning  Database  (DPPDB). 
o  The  3D  models  of  the  TST  objects  are  too  easy  to  pick  out  (initial  detection),  as 
they  “lay  on  top”  of  the  terrain  instead  of  being  part  of  it,  thereby  providing  a 
false  sense  of  the  level  of  difficulty  of  initial  TST  detection  with  a  video  sensor. 

•  TES-N  could  not  do  any  parsing  or  processing  of  the  telemetry  data  provided  by  the  ISR 
video  platform  M&S  system  other  than  display  it,  on-screen,  “burned  in”  as  part  of  the 
video  images  themselves. 

Imagery  via  JCA  Imagery  from  simulated  national  and  other  sources  was  produced  in  NITF 
format  by  the  AutoSIGS  system  at  M&S  Central  in  Newport,  and  then  transferred  (FTP)  to 
JCA’s  Command  IPL  located  at  ONI  in  Suitland,  MD.  JCA  connectivity  (via  Challenge  Athena 
III  SHF  SATCOM)  allowed  users  aboard  BLR  to  access  the  JCA  IPL  (via  the  web-based  Quick 
Query  or  Q2  application),  and  pull  the  images  down  to  the  BLR  IPL.  From  there  they  could  be 
accessed  by  either  PTW  or  TES-N,  the  latter  of  which  could  pull  the  images  over  to  its  own 
system  server,  and  process  the  NITF  headers  to  register  the  images  in  its  DBO  (Database 
Organizer)  application. 
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•  There  were  two  major  hurdles  to  successful  use  of  this  method  of  image  file  transfer: 

o  Getting  permissions  to  access  the  “real  world”  JCA  IPL  is  a  long  and  difficult 
process. 

o  Modifying  AutoSIGS  software  to  allow  production  of  NITF  headers  with  a 
country  code  of  something  other  than  the  default  CC. 

•  Simulated  AutoSIGS  image  quality 

o  was  sufficient  for  analysts  to  run  through  proper  procedures, 
o  was  insufficient  for  any  experimentation  involving  actual  imagery  analysis, 
targeting,  or  battle  damage  assessment. 

U-2  Dragon  Lady  simulation  (from  AFSERS-TENCAP  aboard  BLR)  Attempts  were  made  to 
simulate  the  inputs  into  TES-N  that  would  come  from  a  U-2  Dragon  Lady  aircraft  as  if  it  were 
downlinking  directly  to  BLR.  These  inputs  fall  into  two  categories: 

•  Images:  AFSERS-TENCAP  on  BLR  would  FTP  two  images  per  collection  “event”  in 
NITF  format  to  TES-N:  a  low-resolution  image  to  the  TES-N  Screener  application,  and  a 
high-resolution  image  of  that  same  area  of  coverage  to  the  TES-N  DBO  application. 

•  Telemetry:  AFSERS-TENCAP  provided  a  data  stream  (UDP)  to  TES-N  that  tells  where 
the  simulated  U-2  is  located  at  any  given  time. 

This  capability  worked  only  briefly  during  TT03/FBE-K  (last  two  days  of  CPX)  because  of  a 
number  of  complex  issues  including  an  initial  lack  of  mission  plans,  an  initial  lack  of  a  required 
software  script,  errors  in  subsequent  mission  plans,  and  suspected  software  problems  in  TES-N 

Several  issues  arose  with  regard  to  this  simulation: 

•  There  exists  no  capability  in  AFSERS-TENCAP  to  provide  the  “waterfall”  type  of 
display  in  the  TES-N  Screener  application  that  one  would  get  from  a  live  U-2  aircraft. 

•  The  AFSERS-TENCAP  base  imagery  was  a  mix  of  5-  and  1 -meter  resolution  stitched 
together,  providing  significantly  better  resolution  in  some  areas  (where  there  was  1 -meter 
coverage)  than  the  base  imagery  used  in  AutoSIGS  and  AFSERS-MUSE. 

•  Receiving  and  processing  the  AFSERS-TENCAP  telemetry  data,  required  that  TES-N 
run  a  script  custom  built  for  the  task  that  is,  apparently,  not  part  of  the  standard  TES-N 
version  5.0. 

•  AFSERS-TENCAP  simulated  SAR  imagery  was  illegible  by  TES-N. 

o  Work-around,  have  simulated  U-2  fly  an  ASARS  sensor,  produce  EO  images,  and 
players  pretend  they  were  seeing  SAR. 

ELINT  /  ESM  Attempts  were  made  to  send  simulated  ELINT/ESM  from  various  M&S  sources 
to  the  Tactical  Data  Dissemination  System  (TDDS)  Network  Management  Center  (TNMC)  to  be 
put  onto  the  TDDS  broadcast,  with  receipt  of  the  broadcast  on  BLR  via  organic  means,  and 
processing  of  exercise/experiment  ELINT  using  the  GALE  software  in  TES-N. 

•  Successful  receipt  was  achieved  from 

o  JQUAD  (Camp  Smith,  HI) 
o  JSAF-ASSET  (NWDC  Newport.  RI) 

o  ISR  UUV-CSIM  (NUWC  Newport,  RI)  (never  successful  going  direct  to  TNMC 
but  email  draft  TACELINT  to  ASSET  Simms  Hall  then  sent  to  TNMC. 
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•  TES-N  GALE  was  unable  to  receive,  process,  and  display  TACELINT  messages  from 
ISR  UUV  that  reported  an  LOB. 

o  These  messages  were  apparently  being  received  and  processed  by  GCCS-M. 
o  Work-around,  the  M&S  operators  in  Newport  sent  the  TACELINTs  as  very  thin, 
elongated  ellipses  that  would  look  like  a  single  line  on  the  display. 

COMINT  CPX:  COMINT  injects  were  to  be  crafted  by  Kunia  Regional  SIGINT  Operations 
Center  (KRSOC)  scripters  who  were  resident  in  the  TT03  JECG  at  Camp  Smith,  HI.  Injects 
would  be  sent  via  SI  broadcast  to  BLR  and  received  by  a  COMINT  analyst  using  TES-N. 

•  COMINT  injects  were  received  only  on  SCI  GCCS-M,  as  that  is  the  way  the  BLR  SCI 
architecture  was  configured. 

o  The  COMINT  analyst  at  the  SCI  GCCS-M  would  receive  the  injects  as  emails, 
print  them,  and  sneaker-net  them  to  the  TST  team  manning  TES-N  terminals. 
FTX:  KRSOC  scripters  could  not  stay  for  the  FTX. 

•  COMINT  injects  were  from  the  NWDC  Facilitator  crafting  a  GESNSER-level  COMINT 
spot  report,  and  emailing  the  report  to  as  an  “initial  tipper”. 

Other  issues  prevented  adequate  COMINT  for  both  CPX  and  FTX. 

•  TES-N  does  not  have  any  true  COMINT  analysis  tools  (as  does  SCI  GCCS-M). 

o  C7F  cryptologists  have  chosen  to  not  use  TES-N  for  COMINT  analysis, 
o  Consequently,  none  of  the  required  connectivity  (other  than  JWICS  Intelink  web¬ 
browsing  access,  and  SCI-level  chat)  for  using  SCI  TES-N  was  not  in  place  for 
use  during  TT03/FBE-K. 

•  TES-N  Information  Support  Server  Environment  Guard  was  non-functional  on  BLR. 

o  Could  not  move  data  from  the  SCI  to  the  GENSER  side  of  TES-N. 


5.6.3  TES-N  Outputs 

Target  nomination  messages  (ATI.ATRs)  to  ADOCS  and  to  TST  Target  Folder  Server  The 
objective  was  for  the  TST  nomination  analyst  to  use  TES-N  to  create  a  target  nomination 
message  (in  USMTF  “ATI.ATR”  format),  and  to  send  that  nomination  message  (via  SMTP)  to 
the  ADOCS  server  on  BLR,  and  to  the  TST  Target  Folder  server  at  NWDC.  [ADOCS  would 
receive  the  ATI.ATR  from  TES-N  and,  after  parsing  it,  would  send  another  ATI.ATR  to  the  TST 
Target  Folder  server;  the  target  folder  for  any  given  TES-N  created  TST  nomination  would  have 
both  the  ATI.ATR  directly  from  TES-N  and  from  ADOCS]. 

•  Considerable  effort  was  required  to  get  all  systems  interoperating  correctly,  TES-N  LAN, 
ship’s  LAN/Exchange  server,  FBE-K  WAN  and  Exchange  servers,  ADOCS  mail  server. 

•  Once  set  up  properly,  no  problems  were  encountered  until  corrupted  files  in  the  TES-N 
Cross-INT  filter  database  occurred  due  to  log  files  being  over- filled. 

•  Target  Identification  was  a  problem. 

o  Inconsistencies  existed  in  how  target  nominations  were  handled  by  ADOCS  and 
how  they  were  showing  up  in  the  TST  Target  Folder  server, 
o  Fault  was  in  both  TES-N  and  ADOCS,  with  inconsistencies  in  target  line  usage. 
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o  ADOCS  turned  around  an  ATI.ATR  with  fields  out  of  order  and  truncated. 


Images  related  to  target  nominations  to  PTW  for  aimpoint  refinement  The  objective  was  for  the 
TST  nomination  analyst  to  attach  the  image  or  several  images  (e.g.,  video  “chips”  showing  the 
TST)  to  the  outgoing  target  nomination,  and  send  the  nomination  simultaneously  to  three  places: 

•  ADOCS  to  begin  weapon-target  paring  and  engagement  processes. 

•  TST  Target  Folder  server  to  either  create  a  new  target  folder  or  update  an  existing  target 
folder. 

•  PTW  to  begin  the  aimpoint  refinement  process. 

The  version  of  PTW  used  on  BLR  could  not  receive  and  parse  ATI.ATR  messages  (i.e.,  did  not 
have  the  DTMS  software  used  in  MC02/FBE-J).  The  work-around  was  supposed  to  be  that  the 
PTW  operator  would  open  the  target  folder  after  it  had  been  created  in  the  TST  Target  Folder 
server  and  pull  down  the  images  from  there. 

•  TES-N  does  not  allow  images  to  be  attached  to  outgoing  ATI.ATRs. 

o  All  images  captured,  chipped,  and  saved  (as  NITF)  in  TES-N  had  to  be  manually 
transferred  (FTP)  to  PTW.  The  PTW  operator  would  then  pull  up  the  images  and 
conduct  aimpoint  refinement,  then  save  the  images  (as  both  JPEG  and  NITF)  to  a 
shared  directory  on  the  BLR  IT-21  LAN. 

Images  related  to  target  nominations  to  TST  Target  Folder  Server  The  objective  was  for  the  TST 
nomination  analyst  to  attach  images  to  the  outgoing  target  nomination  so  that  the  TST  Target 
Folder  server  could  add  the  image(s)  to  the  TST’s  target  folder. 

•  The  new  version  5.0  of  TES-N  software  still  cannot  attach  images  to  ATI.ATRs. 

o  The  workaround  was  to  use  MS  Outlook  to  create  a  one-line  ATI.ATR  email 
(using  the  “TNO”  line  only)  with  subject  line  “Target”,  pull  the  image(s)  from  the 
shared  directory  and  attach  to  the  email,  and  send  to  the  TST  Target  Folder 
server. 

•  TST  Target  Folder  server  worked  well. 

•  The  NWDC  TST  Target  Folder  server  application  was  simple  but  powerful  prototype. 

U-2  mission  plan  creation  and  output  to  AFSERS-TENCAP  A  well-written  help-tutorial  on-line 
in  TES-N’s  EMPS  application  was  used  to  guide  creation  a  mission  plan  to  output  to  AFSERS- 
TENCAP  for  its  use  in  providing  a  simulated  feed  of  U-2  imagery  and  telemetry  back  to  TES-N. 
The  plan  consisted  of  a  navigation  plan  and  a  collection  plan  built  using  a  specific  set  of 
collection  requirements  for  a  specific  sensor  type,  associated  with  a  specific  aircraft  tail  number, 
flying  a  specific  track,  downlinking  to  a  specific  ground  station. 

•  EMPS  uses  different  maps  than  ITD. 

•  Not  only  does  it  load  the  maps  from  a  different  set  of  files,  but  the  user  interface  (e.g., 
zoom,  pan,  etc.)  is  completely  different  (and  very  cumbersome). 

•  AFSERS-TENCAP  can  only  reliably  simulate  ASARS  sensors. 

o  AFSERS-TENCAP  could  not  ingest  the  initial  U-2  mission  plans  built  for  the  EO 
sensor  packages  (SYERS  and  SYERS  2). 

DIOP  of  U-2  imagery  and  telemetry  to  ISRM  (CPX)  and  ESSEX  RTC  (FTX)  The  objective  in 
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CPX  was  to  have  the  U-2  simulation  coming  into  TES-N  from  AFSERS-TENCAP  turned  around 
to  ISRM  (a  TES  RTC)  at  Hickam  AFB  using  the  TES-N  Data  Input/Output  Port  (DIOP).  The 
DIOP  connectivity  between  BLR,  ISRM,  and  ESX  RTC  tested  successfully  using  recorded 
mission  tapes  and  demo  files  built  from  actual  U-2  missions  specifically  to  demonstrate  and  train 
the  DIOP  capability  when  no  live  U-2  was  airborne  and  downlinking. 

•  AFSERS-TENCAP  simulation  stream  cannot  be  “DIOP’d”. 

o  AFSERS-TENCAP  uses  different  processes  (FTP  for  imagery  and  UDP  for 
telemetry)  to  provide  the  inputs  to  TES-N  than  a  live  U-2  (which  would  be 
sending  it  through  the  CDL-N  and  CIP),  thus  the  AFSERS-TENCAP  feeds  could 
not  be  turned  around  using  DIOP. 

File  transfer  to  ISRM  (CPX)  and  ESSEX  RTC  /  RTC  Lites  (FTX)  Because  “DIOP”  is  only  for 
the  transfer  of  U-2  imagery  that  is  being  (or  has  just  been)  directly  downlinked,  other  file  types 
must  be  exchanged  between  TES-N  and  remotes  like  ISRM  and  RTCs  using  standard  means 
such  as  FTP  and  SMTP.  During  FTX  only,  three  RTC  Lites  were  employed,  one  aboard  the 
vSSN  (virtual  submarine  simulator  at  NUWC,  Newport,  RI),  one  aboard  the  E2XV 
(Experimental  Hawkeye-2003  surrogate  van  in  the  NWDC  parking  lot  in  Newport,  RI),  and  one 
aboard  the  virtual  DDX  (at  NSWC  Dahlgren,  VA). 

•  FTP  and  SMTP  worked  great. 

•  RTC  Lites  worked  —  eventually. 

o  RTC  Lite  at  NUWC  was  fairly  easy  to  get  up,  configuring  the  others  was  difficult, 
o  The  actual  utility  of  RTC  Lites  to  “virtual  shooter”  nodes  remains  indeterminate. 

Cross-INT  replication  from  TES-N  to  ISRM  (CPX)  and  ESSEX  RTC  (FTX)  Replication  of 
TES-N’s  Cross-INT  database  was  attempted  to  both  ISRM  (CPX)  and  the  ESX  RTC  (FTX),  but 
with  very  limited  success. 

•  During  CPX,  Cross-INT  was  not  replicated  to  ISRM  due  to  ISRM  instability  problems. 

•  During  FTX,  Cross-INT  was  replicated  to  ESX  RTC. 

•  Target  Nominations  created  in  TES-N  are  not  replicated  to  ISRM  /  RTC. 

5.6.4  COP  Issues 

TST  location  output  to  COP  (i.e.,  Manual  Contact  to  GCCS-M)  for  “tracking”  and  SA:  The 
objective  was  for  the  TST  nomination  analyst  to  not  only  create  an  ATI.ATR  as  above,  but  to 
then  use  TES-N’s  rudimentary  interface  to  GCCS-M  to  input  the  target  into  the  COP  as  a  track, 
for  the  situational  awareness  of  ALCON,  and  to  assist  (theoretically)  in  the  “tracking”  of  the 
TST  while  waiting  for  it  to  be  engaged. 

•  The  TES-N  output  to  GCCS-M  only  worked  for  two  days  at  the  same  rudimentary  and 
suboptimal  level  at  which  it  was  working  for  MC02/FBE-J;  for  the  remainder  of 
TT03/FBE-K  it  was  functionally  inoperative. 

•  GCCS-M  configuration  on  BLR  was  sub-optimal. 

o  BLR  had  a  wide  variety  of  serious  issues  (e.g.,  different  software  versions  from 
machine  to  machine),  some  of  which  took  the  entire  event  to  straighten  out. 
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•  TES-N  output  to  GCCS-M  was  inoperative  on  BLR  for  CPX. 

o  Even  with  the  new  TES-N  version  5.0,  there  was  no  improvement  in  TES-N ’s 
ability  to  output  to  GCCS-M  from  what  was  used  in  MC02/FBE-J. 
o  A  workaround  with  the  TES-N’s  Cross-INT  database  was  developed,  then  went 
down  when  nothing  could  be  saved  to  that  database. 

GCCS-M  COP  Tracks  into  TES-N  ITD  In  addition  to  TES-N’s  rudimentary  capability  to  send 
“Manual  Contacts”  to  GCCS-M,  COP  tracks  can  also  be  sent  from  GCCS-M  to  TES-N.  The 
objective  of  attempting  to  do  so  was  to  provide  a  richer  context  of  contacts,  tracks,  Blue  ISR 
asset  locations,  etc.  in  TES-N  for  the  analysts  trying  to  find  and  fix  TSTs. 

•  TES-N’s  incoming  “Message  and  Data  Log”  showed  a  good  number  of  incoming  tracks 
from  GCCS-M,  but  those  tracks  did  not  appear  to  be  parsing  into  the  TES-N  ITD. 

•  When  GCCS-M  tracks  coming  into  TES-N  were  able  to  be  brought  up  on  the  ITD  it  did 
not  display  any  track  labels. 

o  GCCS-M  tracks  in  TES-N’s  ITD  appeared  in  their  proper  locations  but  the 
symbols  do  not  have  any  labels  associated  with  them  (e.g.,  no  track  names), 
making  them  all  but  functionally  useless  to  the  TST  team, 
o  TES-N  symbology  was  used,  which  is  based  on  MIL-STD-2525,  not  GCCS-M 
symbololgy 

M&S  simulated  ISR  asset  display  in  GCCS-M  COP  By  the  end  of  FTX,  all  of  the  simulated 
Blue  ISR  assets  active  in  M&S  were  simultaneously  displayed  on  BLR’s  GCCS-M  COP  with 
appropriate  labels  (e.g.,  two  ISR  UUVs,  two  Predator  UAVs,  one  U-2). 

•  This  was  the  first  time  that  this  has  happened  in  an  FBE.  The  key  enablers  were  very 
closely  coordinated  troubleshooting  between  the  NWDC  Facilitator,  the  FBE-K  ATO 
builder,  the  M&S  Director,  and  the  GCCS-M  Tech  on  BLR. 


5.7  FIRES  PLANNER  OBSERVATIONS 

These  results  are  extracted  from  Appendix  E.  For  a  complete  description  of  experiment  planning 
and  execution  from  the  Fires  planner  viewpoint,  see  that  appendix.  Those  deemed  to  have  had 
the  most  significant  impact  on  achieving  the  Fires  Initiatives  objectives  are  discussed  here.  The 
presentation  in  the  appendix  is  an  observation,  a  discussion,  and  a  recommendation.  The 
discussions  are  omitted  or  shortened  here. 


5.7.1  Sea  Strike  Operational  Planning 

Planning  Directive  No  experiment  directive  was  published  for  this  FBE. 

Discussion :  The  Planning  Directive  is  a  Rosetta  stone  of  infonnation  that  outlines 
responsibilities,  functions,  and  path  toward  execution  of  an  experiment  event.  Lack  of  this 
document  can  cloud  fleet  numbered  responsibilities  and  makes  “arrangements”  for  support  non¬ 
binding  and  unofficial. 
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Recommendation :  Use  this  instrument  in  every  FBE  and  LOE  that  is  conducted. 


Forward  FBEs  and  NWDC  Fleet  Presence  Forward  presence  by  the  NWDC  staff  and  key 
planners  was  lacking. 

Discussion :  Forward  fleets  require  constant  attention  during  the  FBE  planning  process. 
During  FBE  Kilo,  unifonned  initiative  leads  were  present  at  the  forward  fleet  toward  the  end  of 
the  planning  process,  but  many  of  the  other  key  planners  did  not  interact  with  the  fleet  on  a 
substantial  basis  until  they  arrived  for  execution  of  the  experiment. 

Recommendation :  Attempt  to  get  key  planners  forward  often  in  the  planning  process  and 
ALWAYS  hold  the  Final  Planning  Conference  at  the  forward  numbered  fleet  home  location. 

This  will  leverage  fleet  interaction  and  participation. 

Fleet  Interface  and  Fleet  Initiative  Sponsors  No  uniformed  numbered  fleet  sponsor  (uniformed 
warfighter)  for  the  Sea  Strike  Initiatives  was  identified  or  utilized. 

Discussion :  The  Sea  Strike  Initiatives  did  not  have  substantive  uniformed  numbered  fleet 
representation  throughout  FBE  Kilo  (planning  and  execution).  Not  having  warfighter 
sponsorship  at  the  numbered  fleet  level  for  FBE  initiatives  is  unacceptable. 

Recommendation :  Use  the  experiment  directive  to  outline  the  fleet  sponsorship 
requirement  and  do  not  examine  initiatives  that  do  not  have  proper  uniformed  sponsorship  within 
the  numbered  fleet  staff. 


5.7.2  Sea  Strike  Operational  Execution 

IKA  Support  IKA  support  to  the  FBE  was  minimized  due  to  MBC  participation  in  the  2nd  Fleet 
LOE.  There  was  no  coordinated  IKA  support  for  FBE  execution. 

Discussion'.  No  IKA  lead  planning  or  execution  support  for  the  FBE  was  responsible  for 
many  delays  and  training  problems.  Ad-Hoc  /initiative  level  IKA  measures  had  to  be 
implemented  on  the  fly  to  support  FBE  execution.  To  exacerbate  this  matter,  no  clear  level  of 
IKA  support  was  ever  articulated  to  the  planners  during  the  planning  process. 

Recommendation'.  Identify  IKA  (or  other  initiative  area)  participation  level  in  FBE  and 
ensure  that  it  is  maintained. 

Fleet  Execution  Support  Numbered  fleet  staff  support  was  abysmal  for  the  Sea  Strike 
Initiatives.  The  promised  JFACC  support  was  also  minimal  and  not  what  had  been  planned. 

Discussion'.  This  lack  of  support  in  all  these  area  was  the  largest  single  factor  in  not 
realizing  the  experimental  potential  of  the  Sea  Strike  efforts  in  FBE  Kilo.  This  could  be  seen 
during  the  planning  process  but  was  not  corrected  by  the  MBC  uniformed  staff. 

Recommendation'.  Early  and  frequent  interaction  with  the  uniformed  staff  at  the  ACOS 
level  is  required  for  all  initiatives  in  an  FBE,  especially  within  a  forward  numbered  fleet. 


5.7.3  Sea  Strike  Backdrop/Scenario 

FBE  overlay  on  Exercise  Construct  FBE  Kilo  construct  only  loosely  fit  Tandem  Thrust  03. 
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Discussion :  The  overall  FBE  construct  that  was  layered  over  the  exercise  construct  was 
adequate  for  execution  had  the  exercise  construct  been  completed.  Database  testing  for  the  event 
was  woefully  lacking  and  joint  force  (JFACC)  participation  was  almost  nonexistent.  This 
resulted  in  errant  databases  (MIDB,  AODB,  BSCMs),  that  did  not  function  properly. 

Recommendation :  Planner  and  technologies  must  participate  in  any  exercise  database 
testing  events  that  are  integrated  into  the  FBE  construct. 

Exercise  Augmentees  C7F  only  received  a  small  percentage  ( — 30%)  of  the  planned  staff 
augmentation  and  component  augmentation  required  to  carry  out  the  Sea  Strike  initiatives. 

Discussion :  Events  beyond  the  control  of  both  the  MBC  and  the  numbered  fleet  resulted 
in  manpower  shortages  that  greatly  hindered  the  FBE  effort.  While  these  may  have  been 
unavoidable,  they  were  foreseen.  Prior  to  execution,  manning  go/no  criteria  need  to  be 
established  and  utilized  to  prevent  execution  of  events  just  for  the  sake  of  “doing  something.” 

Recommendation-.  Institute  manning  go  /  no  go  levels  during  the  planning  process.  Do 
this  in  concurrence  with  the  numbered  fleet.  Be  prepared  to  not  execute  portions  of  an  FBE  if 
these  criteria  are  not  reached. 

Scenario  The  FTX  scenario  did  not  match  (very  closely),  the  FBE  Sea  Strike  live  force  scenario. 

Discussion :  This  problem  was  due  in  most  parts  to  the  CJTF  (C7F)  fighting  the  sim  and 
live  scenarios  together  when  they  were  designed  to  be  separate.  While  it  may  be  out  of  the 
MBC’s  control  to  drive  this  during  execution,  there  is  room  to  avoid  this  by  proper  prior 
planning,  which  was  not  the  case  in  FBE  Kilo.  This  problem  is  directly  related  to  lack  of 
numbered  fleet  involvement  in  the  planning  cycle. 

Recommendation-.  Force  a  higher  level  of  fleet  experiment/exercise  integration 
familiarization  early  and  often  in  the  planning  process. 

Assumptions  and  Required  Products  An  assumption  was  made  by  the  FBE  planning  staff  that 
certain  products  required  for  FBE  execution  (AODB,  MIDB,  BSCMs,  etc. . .)  would  be  available. 

Discussion'.  The  database  test  was  inadequate,  resulting  in  errant  information  for  use  in 
the  XC4I  systems  used  during  the  FBE. 

Recommendation-.  NWDC  must  participate  with  both  planners  and  technologies  in  the 
database  test  process.  If  products  required  are  substandard,  then  they  must  be  identified  and 
corrected  prior  to  execution 


5.7.4  Sea  Strike  Technical/xC4I 

Shipboard  System  Specifications  USS  Blue  Ridge  has  a  10  mb  switch  backbone  that  is 
connected  via  155  mb  links.  This,  along  with  inconsistent  network  card  setting  hindered 
ADOCS  use  during  the  FBE. 

Discussion-.  Standard,  shipboard  LAN  configurations  that  support  ADOCS  need  to  be 
established.  This  applies  to  switch,  link,  and  network  card  settings  on  these  machines. 
Hardware  limitations  may  require  platforms  to  set  up  multi-server  configurations  to  reduce  the 
effect  of  less  modern  network  backbones. 

Recommendation-.  Set  ISNS  ADOCS  standards  prior  to  install  and  configure 
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accordingly. 


Recommended  Shipboard  System  Configurations  USS  Blue  Ridge’s  LAN  will  require  specific 
ADOCS  configurations  to  support  usage  on  that  platform. 

Discussion :  To  reduce  the  effect  of  a  less  modern  backbone,  placement  of  ADOCS 
servers  in  a  multiserver  configuration  and  standardization  of  network  interfaces  is  required. 

Recommendation-.  Place  ADOCS  servers  in  the  following  spaces:  JIC,  JOC  (master), 
JAOC.  Configure  these  machines  so  they  are  all  pointed  at  the  switches  where  the  clients  they 
support  reside. 

ADOCS  Recommend  Software  /  Hardware  Changes  Many  recommended  changes  to  ADOCS 
were  compiled  during  the  FBE. 

Discussion :  ADOCS  changes  are  indicative  of  command  and  control  capability 
requirements  that  currently  exist. 

Recommendations-. 

Software 

1 .  Ability  to  pair  a  target  to  an  ITO  mission  via  a  button 

2.  Ability  to  highlights  targets  in  Fires  and  JSTM  managers  when  changes  have 
occurred...  alert? 

3.  A  configurable  Fires  Manager  (within  the  ADOCS  GUI). 

4.  Add  “hour  glass”  icon  to  ADOCS  to  display  system  working. 

5.  TST  supported  CDR  indicator  in  JTSTM. 

6.  Hot  link  to  ROE  url. 

7.  Hot  link  to  TST  priorities  url. 

8.  Creation  of  a  Combat  Assessment  manager  and  removal  of  that  function  from  the 
Fires/JTST  managers. 

9.  Hot  link  to  target  folder  url. 

Hardware 

1.  Two  (2)  displays  for  ADOCS  users  that  are  doing  target  development  and 
coordination 

JFN  interaction  with  ADOCS  ATI.ATR  target  nomination  from  JFN  was  incomplete. 

Discussion :  ATI.ATR  target  nomination  to  JFN  was  incomplete  and  not  really  viable  for 
usage.  This  problem  needs  to  be  fixed.  It  was  identified  over  2  years  ago  and  is  still  a  problem. 

Recommendation-.  Detailed  ADOCS  -  JFN  testing  to  fix  this  problem.  This  should  be 
completed  in  a  lab  setting  vice  waiting  for  another  FBE. 


5.7.5  Operational  Road-Ahead  and  Other  Recommendations 

ADOCS  Road  Ahead  for  C7F  /  COMPACFLT  /  USPACOM  ADOCS  will  be  integrated  into 
the  PACOM  C2  structure.  FBE  Kilo  was  a  major  event  in  this  transition. 

Discussion'.  ADOCS  use  in  FBE  Kilo  was  the  first  in  a  series  of  event  that  will 
proliferate  ADOCS  across  the  PACOM.  Lesson  learned  from  this  effort  should  be  passed  on  to 
facilitate  a  higher  level  of  functionality  in  future  PACOM  events  (IPD,  TF04,  CG04). 
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Recommendation :  Pass  detailed  ADOCS  report  to  PACOM  via  C7F  and  COMPACFLT 
to  help  this  effort  along.  Report  should  be  a  NWDC/JPSD  collaborative  effort. 


Time  Critical  Targeting  Functionality  Afloat  The  Xray  Papa  cell  was  an  excellent  test  case  for 
familiarization  of  the  TCTF  concept  to  the  fleet. 

Discussion :  TCTF  is  a  USAF  program  that  outlines  the  C2  requirements  and  systems  for 
conducting  TCT  operations.  In  support  of  JCC  and  JCC  (Afloat),  the  USN  needs  to  further 
refine  this  concept  to  support  both  joint  and  maritime  forces  from  a  flag  configured  platform. 

Recommendation :  Use  TCTF  Afloat  a  starting  point  for  future  Sea  Strike  initiatives. 

Coalition  Fires  Experimentation  Coalition  shooter  information  requirements  where  not  met  by 
the  RMG  technology. 

Discussion :  The  RMG  technology  and  its  approved  rulesets  did  not  allow  the  coalition 
forces  to  fully  integrate  with  the  other  shooter  platforms.  This  problem  resulted  in  SA 
deficiencies  on  both  sides  of  the  guard. 

Recommendation:  Develop  two  paths  for  future  coalition  experimentation,  one  based  on 
full  network  integration  and  the  other  based  on  LNO  supported  by  US  releasable  C2  systems  and 
backbone.  Both  are  viable  and  critical  to  continued  integration  of  coalition  forces. 

Xray  Papa  and  Maritime  Component  Time  Sensitive  Targeting  The  Xray  Papa  cell  identified  a 
time  sensitive  targeting  gap  at  the  maritime  component  level  that  needs  to  be  addressed. 

Discussion:  JFMCC’s  conduct  of  broad  scale  TST  operations  that  are  integrated  with 
other  components  is  beyond  the  traditional  role  of  the  Bravo  Papa.  A  staff  function  at  the 
operational  level  (JFMCC)  that  supports  TST  prosecution  is  required. 

Recommendation:  Integrate  this  effort  with  the  TCTF  effort  described  above  to  help 
identify  maritime  TST  command  and  control  requirements  of  the  future. 


5.8  JFN  PROGRAM  OFFICE  RESULTS 

During  FBE-Kilo  the  JFN  Program  Office  gathered  information  about  the  performance  of  that 
system.  A  report  has  been  delivered  to  the  Program  Office  and  the  following  are  excerpts  from 
that  report. 

The  Tandem  Thrust  specific  analytical  objectives  for  TT03  were  based  on  PEO-IWS-6-C 
specific  guidance  on  how  to  best  support  present  and  future  implementation  of  TES-N  systems  to 
support  warfighting.  This  analysis  effort  will  provide  information  to  the  modeling  effort  and 
provide  feedback  to  PEO-IWS-6-C  to  support  future  acquisition  and  fielding  decisions. 

Initially,  the  high  level  objectives  for  this  experiment  were: 

•  Document  the  Joint  TES  architecture  and  interoperability  in  order  to  provide  operational 
and  technical  insight  to  modeling. 

•  Document  TST  timeline  events  in  TT03  TES  scripted  combat  operations. 

•  Document  TES  functionality  and  products  in  the  IPB  process. 
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•  Contribution  to  Operational-  and  Tactical  Level  Situational  Awareness 

•  Document  the  functions  and  capabilities  of  AFATDS  and  ADOCS  in  the  JFN 

•  Provide  insight  to  support  system  acquisition  decisions  as  it  supports  the  Distributed 
Common  Ground  Surface-Station  concept  (DCGS). 

•  Provide  insight  to  operator  training  and  JFN  CONOPS  development. 

Because  of  a  shortage  of  funds  and  the  poor  quality  of  some  of  the  technical  data,  analysis  was 
not  conducted  some  of  the  objectives.  Only  the  following  of  the  above  objectives  were  there 
minimally  sufficient  data  to  provide  some  analytical  insight. 

•  Document  the  Joint  TES  architecture  and  interoperability  in  order  to  provide  operational 
and  technical  insight  to  modeling. 

•  Document  TST  timeline  events  in  TT03  TES  scripted  combat  operations. 

•  Document  TES  functionality  and  products  in  the  IPB  process. 

•  Interface  performance  of  TES-N  with  other  systems  (specifically,  ADOCS). 

5.8.1  TST  Thread  Example 

In  order  to  detennine  JFN  performance,  two  detect-to-engage  threads  were  tracked.  Infonnation 
from  those  threads  is  presented  below. 

TST  Thread  Example:  (SA-15,  16  April  03) 

Time  (local)  Event 

Received  5  ELINT  hits  that  correlated  to  a  radar  for  an  S A- 1 5  site 
(SIPRnet  Email  from  USS  Blue  Ridge) 

P3-AIP  tasked  (via  JECG)  to  provide  video  in  vicinity  of  the  ELINT  contacts. 

(SIPRnet  Email  from  USS  Blue  Ridge) 

Video  from  P3  received  and  analyzed  at  JFN  MFWS.  Target  was  easily  identified. 
(SIPRnet  Email  from  USS  Blue  Ridge) 

JFN  Image  Analysts  refined  location  and  pass  ELINT  data  to  AOC  (Hickam) 

(SIPRnet  Email  from  USS  Blue  Ridge) 

1240  ELINT  Contact  Report  received  from  JFN  (Blue  Ridge)  to  ISR-M  (Hickam) 

(CHAT  Sidebar  12) 

1240  TCT  Chief  and  Deputy  CCO  discuss  potential  TST  and  attack  options. 

Attack  Ops  requests  initial  target  coordinates  from  Targeteer  and  requests 
Targeteer  to  provide  potential  platfonns  with  load-outs  on  current  ATO. 

1246  Attack  Coordinator  prepares  strike  package  options 

1251  SIDO  consults  with  TCT  Chief  regarding  expected  imagery  and  DMPI’s 

1257  TCT  Chief  briefs  CCO  andJF  ACC  about  SA-15. 
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1300  ISR-M  Operator  chats  with  JFN  Operator  (USS  Blue  Ridge)  and  tells  them  that 
strike  package  is  prepared  but  imagery  required  for  more  precise  coordinates  and 
collateral  damage  assessment.  (CHAT  Sidebar  12) 

1305  TCT  Chief  provides  status  brief  for  CCO  and  JFACC.  JFACC  decides  that 

mensuration  is  not  required  because  strike  package  calls  for  Laser  Guided  Bomb 
(LGB).  JFACC  “not  worried  about  collateral  damage  because  several  DMPI’s 
in  vicinity  of  SA-1 5  were  hit  earlier  in  the  day” 

1308  ISR-M  Operator  chats  with  JFN  Operator  (USS  Blue  Ridge)  and  requests  refined 
coordinates.  Explains  that  JFACC  does  not  want  to  wait  for  imagery. 

(CHAT  Sidebar  12) 

1309  JFN  Operator  mentions  that  he  was  unsuccessful  in  sending  imagery  and  will 
forward  coordinates.  (CHAT  Sidebar  12) 

1310  ISR-M  Operator  receives  refined  coordinates  from  JFN  Operator  via  Chat  circuit 
and  provides  to  SIDO  and  TCT  Chief. 

1310  Coordinates  are  passed  to  Attack  Coordinator  and  JFACC  directs  immediate  execution. 

1311  TCT  Chief  discusses  Phase  II  BDA  Plan  with  SIDO 

1313  TCT  Chief  requests  JFN  coordinate  additional  imagery  for  BDA.  (CHAT  Sidebar  12) 

1318  JFN  Operator  reports  that  P3  tasked  (via  exercise  controller)  to  provide 
additional  video  after  the  strike. 

1325  Additional  video  collected  and  displayed  on  JFN.  JFN  Operator  could  not 
forward  imager  to  ISR-M 

1331  In  response  to  queries  from  AOC  (TCT  Chief),  JFN  analyst  reported  that  image 
showed  black  smoke  from  radar  station  -  Destroyed.  (CHAT  Sidebar  12) 

1331  Event  Completed 


TB0062 


Time 

Event 

Data  Source 

Remarks 

010404May 

BR  TES-N  nominates  CDCM 
transporter  for  targeting 

ADOCS 

Mission 

History  Logs 

Dwell  time  is  to  010604 
May  (2  hours) 

010428May 

J2  Ops  states  that  refined 
coordinates  are  available  for  this 
target. 

IRC  Chat  Logs 

010445May 

The  TST  LNO  asks  the  XP  ISR 
Manager  to  ask  E-2C  to  execute 
mission. 

IRC  Chat  Logs 

TST  ADOCS  is  not 
working 

010455May 

E-2C  identifies  2  x  F/A-18C 
available  for  strike 

ADOCS 

Mission 

History  Logs 

ATO  lists  A/C  availability 
from  010430  to 

010600May 

010455May 

XP  informs  TST  staff  that  they 
must  notify  the  XP  prior  to  using 
Navy  assets. 

IRC  Chat  Logs 

Possible  C2  procedure 
issue. 

010457May 

E-2C  states  to  XP  that  he  has  been 
double  tasked  for  the  same  target 

IRC  Chat  Logs 
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Time 

Event 

Data  Source 

Remarks 

both  by  the  XP  and  the  JTF  TST 

010505May 

TST  LNO  requests  best  TOT  time 
from  E-2C  for  sortie  1025. 

IRC  Chat  Logs 

010513May 

J2  Ops  tasks  UAV  for  BDA  on 
target. 

IRC  Chat  Logs 

010500May 

E-2C  states  that  TOT  was  0520. 

IRC  Chat  Logs 

010533May 

BDA  Imagery  in  target  folder. 
Assessment  is  “unrepairable, 
possible  scrap. . . .catastrophic 
damage..,” 

ADOCS  Logs 

The  decision  event  timeline  for  the  F2T2EA  process  of  TB0062  shows  a  target  executed  in  89 
minutes.  This  process  is  within  the  120  minute  assigned  dwell  time.  This  time  starts  when  the 
JIC  nominates  a  target  for  execution.  The  JIC  continuously  monitors  the  event  as  evidenced  by 
informing  operations  that  geo-refinement  coordinates  are  available  and  by  tasking  an  UAV  for  a 
BDA  mission. 


TB0041 


Time 

Event 

Data  Source 

Remarks 

290318 

Apr 

BR  TES-N  nominates  a 
radar  for  targeting 

ADOCS  Mission 
History  Logs 

290323 Apr 

Target  assigned  a  dwell 
time  from  290418  to 
290518Apr 

ADOCS  Mission 
History  Logs 

290341  Apr 

JTF  ISR  asks  if  TST 
watch  if  they  need  Rivet 
Joint  or  U2  support 

IRC  Chat  Logs 

Based  on  whether  target  is  DF 
because  of  COMINT. 

Declines  offer  because  of 
Predator  availability 

290341  Apr 

COMINT  reported  firing 
sites  in  vicinity  of  Central 
Defense  Command  Center. 

ADOCS  Mission 
History  Logs 

290349Apr 

XP  notifies  E-2C  that  a 
SAM  has  been  located 
over  target. 

IRC  Chat  Logs 

290351  Apr 

XP  asks  Targeting  Officer 
for  geo-refined 
coordinates. 

IRC  Chat  Logs 

Target  folders  for  this  target 
cannot  be  found.  Queries  JIC 

290352Apr 

ISR  Mgr  assigns  UAV  1  to 
cover  target  area 

IRC  Chat  Logs 

290353Apr 

XP  queries  E-2C  if  there 

IRC  Chat  Logs 
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Time 

Event 

Data  Source 

Remarks 

are  air  assets  available  to 
strike  target. 

290356Apr 

XP  begins  coordination 
with  ANZAC  on  assigning 
them  target. 

IRC  Chat  Logs 

2903  5  8 Apr 

E-2C  states  that  target  is  a 
CDCM,  not  SAM. 

IRC  Chat  Logs 

XP  directs  E-2C  to  nominate 
as  target.  Target  being 
worked  by  2  platforms. 

290401  Apr 

E-2C  requests  imagery. 

IRC  Chat  Logs 

XP  states  that  imagery  is  not 
available.  JIC  having 
problems  with  target  folders. 

290403Apr 

UAV  on  station.  Operator 
begins  sending  reports. 

IRC  Chat  Logs 

2904 15 Apr 

JFMCC  is  taking  control 
of  the  target 

ADOCS  Mission 
History  Logs 

E-2C  not  infonned. 

290424Apr 

TST  LNO  reports  ADOCS 
technical  problems. 

IRC  Chat  Logs 

Apparent  problem  with 
different  Zulu  times  affecting 
the  remarks  section. 

290427Apr 

XP  states  that  they  are 
showing  WTP  ANZAC- 
ERGM  on  ADOCS 

IRC  Chat  Logs 

Still  confusion  on  ANZAC 
concerning  when  to  execute. 
ANZAC  can  only  collaborate 
on  ADOCS  in  TCT,  XPA, 

WRD  and  FRD.  Other  blocks 
must  be  transmitted  via  voice 
communications. 

290439Apr 

ANZAC  executes  mission. 

IRC  Chat  Logs 

ADOCS  Mission  History 
records  following:  JFACC 
WTP  at  290433Apr;  MCC 
(ANZAC)  WTP  at 

290420Apr. 

290512Apr 

XP  requests  target 
intelligence  from  JIC. 

IRC  Chat  Logs 

290520Apr 

JIC  confirms  that  UAV  1  is 
tasked  for  BDA 

IRC  Chat  Logs 

The  target  TB0041  timeline  documents  the  F2T2EA  process  for  a  coalition  decision  making 
event.  Timeline  for  execution  is  122  minutes.  What  is  noteworthy  for  this  event  is  how  the 
target  is  processed  by  2  separate  entities  (E-2C  for  an  airstrike  and  the  JFMCC  for  a  surface  fires 
strike).  There  are  indications  that  initially  there  is  a  lack  of  synchronization  by  both  entities. 
There  seems  to  be  some  confusion  on  whether  the  target  is  a  CDCM  or  SAM.  This  confusion 
may  have  delayed  the  decision  making  time  (can  be  surmise  that  the  E-2C  may  have  been 
reluctant  to  send  aircraft  into  the  vicinity.  What  is  finally  resolved  is  that  the  ANZAC  will  be 
the  primary  shooter  with  strike  fighters  providing  back-up.  This  target  apparently  is  developed 
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from  COMINT  sources.  However,  there  seems  to  be  a  cueing  process  as  a  Predator  is  tasked  to 
surveil  the  target  and  ELINT  ISR  sources  are  not  employed.  There  is  a  problem  with  imagery 
availability  from  the  target  folders  that  may  have  slowed  the  process. 


5.8.2  Findings  and  Conclusions 

These  findings  deal  with  the  following  questions: 

•  How  do  TES  products  contribute  to  the  IPB  process? 

•  Do  TES  products  enhance  predictive  analysis  of  enemy  course  of  action? 

This  analytical  objective  focused  on  the  process  and  configuration  of  TES,  GCCS-M  and 
ADOCS  as  they  relate  to  the  IPB  process  in  the  Joint  Intelligence  Center  (JIC).  Doctrinally,  IPB 
provides  a  systematic,  continuous  process  of  analyzing  the  threat  and  environment  in  a  specific 
geographic  area.  It  is  designed  to  support  staff  estimates  and  military  decision  making. 

Applying  the  IPB  process  helps  commanders  selectively  apply  and  maximize  his  combat  power 
at  critical  points  and  times  in  the  battlespace. 

The  JIC  intelligence  staff  was  surveyed  on  whether  the  JFN  enhanced  the  IPB  process  and  TST 
operations.  The  specific  focus  of  JFN  enhancements  was  TES.  There  were  certain  constraints 
to  the  experiment  that  may  have  influenced  their  opinion.  These  constraints  include  manning, 
training,  and  scenario  relevancy.  While  the  sample  was  small;  there  were  some  insights  that 
emerged. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  indicated  that  TES  aided  in 
identifying  gaps  in  the  commands  knowledge  of  the  threat  and  the  current  threat  situation. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  that  TES  products 
were  used  to  portray  threat  models  that  included  doctrinal  templates.  Additionally,  the  same 
percentages  were  reflected  in  the  respondents’  perception  of  TES  products  usefulness  in 
developing  models  that  depicts  threat  courses  of  action. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  on  ADOCS 
usefulness  in  providing  TST  operations  situational  awareness. 

25%  of  the  respondents  disagreed  and  75%  of  the  respondents  had  no  opinion  that  ADOCS 
provided  useful  infonnation  to  continuously  update  the  enemy  situation  template. 

All  respondents  agreed  or  strongly  agreed  that  there  was  effective  coordination  between  the  TES 
imagery  screener,  the  ELINT  screener,  and  the  video  screener. 

All  respondents  agreed  that  the  imagery  analyst  processed  imagery  accurately  and  timely. 

50%  of  the  respondents  agreed  and  50%  of  the  respondents  had  no  opinion  that  the  configuration 
of  the  JFN  systems  in  the  JIC  was  sufficient  to  ensure  fusion  of  intelligence  was  accurate  and 
timely  for  targeting. 
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25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  that  JFN  provided  the 
tools  to  fuse  products  that  would  answer  the  commander’s  priority  intelligence  requirements. 

All  respondents  agreed  or  strongly  agreed  that  the  configuration  of  the  JFN  systems  in  the  JIC 
was  sufficient  to  facilitate  collaboration  between  different  functions. 

50%  of  the  respondents  disagreed  and  50%  of  the  respondents  had  no  opinion  that  track  elements 
on  the  TES  Integrated  Tactical  Display  (ITD)  were  the  same  as  the  GCCS-M  COP. 

66.66%  of  the  respondents  disagreed  and  33.33%  of  the  respondents  had  no  opinion  that 
ADOCS  and  JFN  systems  provided  situational  awareness  of  theater  wide  ISR  operations. 

75%  of  the  respondents  agreed  and  25%  of  the  respondents  had  no  opinion  that  the  JIC  provided 
targeting  data  to  the  JAOC  and  XP  to  support  TST  operations. 

All  of  the  respondents  disagreed  that  the  JFN  systems  were  technically  reliable. 

Conclusions: 

Several  constraints  to  the  data  collection  and  analysis  efforts  preclude  making  definitive 
conclusions.  These  constraints  include:  small  sample  size;  technical  difficulties;  control  of  the 
experimental  design;  and  adequate  manning.  However,  there  are  several  insights  that  can  be 
extracted  form  the  data. 

TES  capabilities  have  the  potential  to  contribute  to  the  IPB  process.  Noteworthy  was  TES 
contribution  to  portray  threat  models  that  included  doctrinal  templates,  and  their  usefulness  in 
developing  models  that  depicts  threat  courses  of  action. 

There  was  not  any  data  to  support  confidence  in  that  TES  and  GCCS-M  had  a  common  picture 
of  the  friendly  and  enemy  situation. 

There  were  indications  that  the  configuration  of  the  JIC  was  sufficient  to  ensure  that  capabilities 
of  different  systems  could  be  applied  to  fusion  of  intelligence  products. 

Technical  performance  was  a  significant  factor  the  limited  optimal  operational  capabilities. 

A  second  high-level  analytical  objective  dealt  with  interface  perfonnance  of  TES-N  with  other 
systems.  Difficulties  covered  previously  in  this  report  prevented  gathering  adequate  information 
to  draw  conclusions  about  this  topic. 


This  page  intentionally  left  blank. 
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6.0  CONCLUSIONS  AND  RECOMMENDATIONS 


6.1  CONCLUSIONS  AND  RECOMMENDATIONS  CONTEXT 

The  analysis  and  reporting  contained  here  for  FBE-Kilo  is  different  than  what  has  been  done  for 
previous  FBEs.  Formerly,  the  concentration  was  on  operational  and  tactical  processes,  how  well 
they  could  be  performed.  Analysts  and  subject  matter  experts  worked  with  data  and  information 
that  had  been  obtained  with  a  focus  on  decision-making,  speed  of  perfonnance,  those  things  that 
lead  to  improved  operational  capabilities.  In  FBE-Kilo  planning,  personnel,  and  equipment 
problems  that  have  been  described  in  former  sections  and  Appendices  resulted  in  processes  not 
being  performed  in  a  way  that  would  yield  much  in  the  way  of  usable  process  data  or 
information. 

As  a  result,  the  majority  of  the  results  and  conclusions  presented  here  deal  with  experiment 
conduct  and  supporting  equipment.  Information  about  operational  processes  that  can  be  gleaned 
is  presented  but  represents  a  small  part  of  the  whole. 

Because  of  the  unusual  nature  of  this  experiment  noted  above,  the  most  valuable  observations 
and  information  are  from  those  people  responsible  for  performing  the  events  and  for  making  the 
equipment  work.  Three  high  quality,  detailed,  and  comprehensive  reports  on  the  experiment’s 
conduct  and  equipment  have  already  been  written  by  these  people  (see  Appendices  C,  D,  and  E). 
Some  of  the  conclusions  and  recommendations  presented  here  are  extracted  from  those 
appendices,  others  come  from  direct  observations  by  the  analysts  who  observed  the  experiment. 
Those  who  wish  to  understand  the  details  of  FBE-Kilo  should  read  completely  the  three 
appendices.  The  extractions  presented  here  cover  their  main  points  in  abbreviated  fashion.  They 
have  included  other  observations  that  are  not  presented  here. 

Conclusions  are  presented  as  Findings  and  Insights  and  many  of  them  are  accompanied  by 
recommendations.  An  overarching  recommendation  for  the  Fires  Initiatives  is  that  the  results 
from  FBE-Kilo  be  used  to  step  back,  assess,  and  improve  the  Navy  experimentation  process.  If 
this  is  done,  the  Kilo  experience  will  prove  to  be  worthwhile. 

Four  Findings  from  the  CPX  phase  of  FBE-Kilo  are  included  with  the  Principal  Conclusions  and 
at  the  end  of  this  section.  They  are  included  because  of  their  applicability  to  all  of  the 
experiment. 

6.2  PRINCIPAL  CONCLUSIONS  AND  RECOMMENDATIONS 

Principal  Conclusions  are  first  presented  in  a  format  meant  to  facilitate  their  use  for 
presentations.  Each  area  of  interest  conclusions  are  presented  on  a  single  page  with  highlights  in 
a  box,  as  might  be  used  for  a  view  graph  or  Power  Point,  followed  by  a  brief  explanation  of  each 
point. 

Principal  Findings  are  presented  in  the  following  order: 

Experiment  (3) 
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Coalition  (3) 

Fires  (5) 

TST  Organization  (1) 

FBE  Data  (1) 

Technology  (4) 

CPX  Extraction  (4) 

The  numbers  in  the  parentheses  are  the  numbers  of  findings  types  in  each  category,  a  total  of  2 1 . 
The  number  is  this  large  because  Findings  in  each  of  the  categories  need  to  be  presented  to 
adequately  represent  FBE-Kilo  results. 

This  ordering  is  used  because  the  more  important  results  from  FBE-Kilo  had  to  do  with 
experiment  perfonnance.  Because  of  the  many  difficulties  that  existed,  initiative  results  were 
difficult  to  obtain.  Equipment  difficulties,  including  connectivity,  caused  many  of  the 
difficulties.  They  are  presented  last  because  they  explain  some  of  the  initiative  results  presented 
before  them. 

A  significant  FBE-Kilo  outcome  was  that  a  large  number  of  experiment  conduct  and  equipment 
improvements  were  identified.  If  the  recommendations  developed  are  implemented,  a 
substantial  improvement  in  experimentation  will  result. 
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FBE-Kilo,  Field  Training  Exercise  Phase 

Experiment  #1  -  Experiment  Planning 

•  No  experiment  planning  directive. 

o  Fleet  support  responsibilities  unclear. 

•  NWDC  staff  forward  presence  lacking. 

•  No  uniformed  Fleet  sponsor  for  Sea  Strike. 

•  Lack  of  continuity  between  experiment  Concept  and  exercise  planning. 


No  experiment  Planning  Directive  was  published  for  this  FBE-Kilo.  It  is  a  necessary  document, 
supplying  information  that  outlines  responsibilities,  functions,  and  path  toward  execution  of  an 
experiment  event.  Lack  of  this  document  can  cloud  numbered  fleet  responsibilities  and  makes 
“arrangements”  for  support  non-binding  and  unofficial. 

Forward  presence  by  the  NWDC  staff  and  key  planners  was  lacking  for  FBE-Kilo.  Constant 
collaboration  with  the  Fleet  is  needed  during  experiment  planning.  Uniformed  initiative  leads 
were  present  at  the  Fleet  toward  the  end  of  the  planning  process,  but  many  of  the  other  key 
planners  did  not  interact  with  the  Fleet  on  a  substantial  basis  until  they  arrived  for  execution  of 
the  experiment. 

No  uniformed  Fleet  sponsor  (uniformed  warfighter)  for  the  Sea  Strike  Initiatives  was  identified 
for  FBE-Kilo  for  planning  and  execution.  Not  having  warfighter  sponsorship  at  the  numbered 
fleet  level  for  FBE  initiatives  severely  hampers  planning  and  coordination. 

A  lack  of  continuity  existed  between  the  development  of  FBE-K  concepts/initiatives  involving 
ISR/JFN,  and  the  actual  FBE-K  planning/implementation  for  FBE-Kilo.  This  discontinuity 
hampered  the  development  of  meaningful  analytic  questions,  and  the  experimental  techniques  to 
help  answer  those  questions. 
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FBE-Kilo,  Field  Training  Exercise  Phase 

Experiment  #2  -  Experiment  Preparation 

•  Some  required  products  not  available. 

•  Lack  of  document  control. 

•  Lack  of  Fleet  staff  participation. 

o  Both  real-world  operations  and  coordination  impacts. 

•  Operational  Sequence/Functional  Flow  Diagrams  insufficient. 

•  COP  development  and  management  insufficient. 


Some  products  required  for  FBE  execution  (AODB,  MIDB,  BSCMs,  etc...)  were  not  available. 
The  test  of  the  database  was  inadequate,  resulting  in  errant  information  for  use  in  the  XC4I 
systems  used  during  FBE-Kilo. 

Like  most  previous  FBEs,  Kilo  suffered  from  a  lack  of  document  control  for  most  of  the  key 
coordinating  documents.  Early  in  the  FBE  planning  stages,  key  coordinating  documents  (and 
their  owners),  should  be  identified  and  implemented  an  FBE-wide  common  methodology  for  the 
cooperative  production,  review,  maintenance,  and  accessibility. 

From  the  ISR  perspective,  FBE-Kilo  degenerated  almost  completely  into  a  JFN  systems  training 
event,  largely  because  participation  by  C7F  Staff  and  Fleet  forces  in  the  planning,  preparation, 
and  execution  was  constrained  to  such  an  extent  as  to  preclude  meaningful  ISR  and  JFN-related 
experimentation.  ISR  and  JFN  related  experimentation  require  numbered  Fleet  full  buy-in  and 
participation,  particularly  the  operations  (N3)  staff.  The  focus  needs  to  be  on  the  experiment 
rather  than  on  Fleet  training/exercises. 

Functional  Flow  Diagrams  (FFDs)  should  be  developed  prior  to  (or  in  conjunction  with) 
Operational  Sequence  Diagrams  (OSDs).  They  describe  who  at  which  functional  nodes  need  (or 
will  provide)  what  information  from  (to)  whom  and  why. 

The  COP  in  FBE-Kilo  did  not  have  explicit  “ownership”  by  any  initiative,  and  was  not 
maintained  to  a  level  required  to  support  ISR  and  JFN  in  support  of  TST.  Early  in  the  FBE 
planning  stages  it  is  necessary  to  identify  who  has  responsibility  for  each  of  the  many  complex, 
interdependent  functions  that  go  into  producing  an  accurate,  stable  COP  from  which  players  will 
be  capable  of  “fighting  the  experiment”. 
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FBE-Kilo,  Field  Training  Exercise  Phase 

Experiment  #3  -  Experiment  Go/No-Go 


•  Significant  shortfalls  to  adequate  experiment  execution  identified  prior  to 
FBE-Kilo. 

•  No  process  exists  to  decide  whether  or  not  to  execute  an  experiment, 

o  Personnel  impacts. 

o  Equipment  impacts. 

•  A  definite  process  for  no-go  is  needed. 

o  A  process  for  comparing  goals  to  capabilities  would  be  required. 


A  combination  of  events  provided  warnings  that  FBE-Kilo  could  not  be  carried  out  as  planned. 
These  were  both  personnel  shortages  to  man  operational  positions  and  equipment  problems.  It  is 
not  worthwhile,  in  hindsight,  to  discuss  whether  or  not  the  experiment  should  have  been 
conducted.  The  experience  does  indicate  that  a  processes  is  needed  for  making  a  go/no-go 
decision. 

Events  as  large  as  an  FBE  naturally  build  up  a  momentum  toward  execution  that  is  almost 
irresistible.  There  does  not  exist  a  process  to  decide  whether  or  not  to  execute  an  experiment.  A 
definite  process  is  needed  that  contains  the  following  steps: 

Examine  current  status. 

Determine  steps  and  effort  needed  to  achieve  full  experiment  requirements. 

Determine  what  additional  can  be  realistically  achieved  with  resources  available. 
Determine  projected  status  at  the  time  of  the  experiment. 

Make  a  go/no-go  decision  or  proper  level  of  scaling  back. 

A  go-ahead  decision  requires  that  the  projected  status  satisfies  a  pre-set  level  of  personnel  and 
system  support  to  carry  out  an  adequate  experiment. 

A  decision  would  not  have  to  be  binary.  It  should  be  possible  to  scale  back  the  experiment  to 
what  is  achievable. 

Implementing  such  a  decision  system  would  require  a  much  better  mapping  of  initiative 
requirements  to  system  and  process  capabilities  than  is  now  available. 


FBE-Kilo,  Field  Training  Exercise  Phase 

Coalition  #1  -  Radiant  Mercury  Guard 

•  Rule  set  did  not  use  the  latest  message  format  used  in  ADOCS 


o  Not  all  data  could  be  transferred 


RMG  bridged  the  security  boundary  between  the  SECRET  US  NOFORN  and  SECRET 
AUSCANUKUS  releasable  networks.  Due  to  budget  and  time  constraints  for  accreditation  of 
RMG,  a  previously  approved  rule  set  was  used. 

•  This  rule  set  did  not  use  the  latest  message  format  used  in  ADOCS. 

o  Not  all  of  the  data  sent  through  RMG  from  SECRET  US  NOFORN  ADOCS  was 
transferred  to  the  Coalition  network. 

•  GCCS-M  COP  was  transmitted  effectively  across  RMG. 

Radiant  Mercury  Guard  was  used  to  filter  and  transfer  structured  messages  for  FBE-K.  To 
exchange  unstructured  messages  (Chat,  e-mail,  VoIP,  web  pages)  between  U.S.  and  Coalition 
systems,  a  human-in-the-loop  ‘air  gap’  (Sneaker-Net)  was  utilized.  Information  from  U.S.  was 
reviewed  and  relevant  information  for  Coalition  was  transferred  across  the  boundary. 

•  Utilized  due  to  the  lengthy  approval  process  for  an  automatic  filtering  system. 

•  Using  Sneaker-Net,  a  direct  transfer  of  chat  messages  was  not  maintained. 

•  Delay  in  message  transfer  was  not  the  major  issue  for  this  system. 

•  E-mail  volume  did  not  increase  the  delay  of  chat  message  transfer. 

The  air  gap  between  the  Coalition  IRC  net  and  FBE  IRC  net  systems: 

•  Introduced  latencies  of  typically  about  seven  minutes. 

•  Was  manpower  intensive  to  pass  information  across  the  gap. 

•  An  automated  filter  (e.g.  ISSE  Guard)  is  required. 

The  transfer  of  web  page  infonnation  was  complicated  and  a  significant  amount  of  time  was 
used  for  this  process. 

•  As  with  Chat,  the  reliance  on  web  portals  to  provide  access  to  infonnation  necessitates  a 
better  solution  to  the  problem  of  integrating  coalition  partners. 
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FBE-Kilo,  Field  Training  Exercise  Phase 

Coalition  #2  -  Coalition  Fires  TTP 

•  No  defined  tactical  C2  process  for  coordinated  Fires, 
o  Operator  confusion  at  ANZAC  and  Coalition  Cell, 
o  Work  focused  on  understanding  process, 

o  Planned  training  not  achieved. 


The  most  significant  issue  encountered  by  Coalition  was  the  absence  of  a  clearly  defined, 
tactical  level,  step-by-step  process  for  the  command  and  control  coordination  of  fires. 

•  Creation  of  a  step-by-step  process  for  fires  coordination  part  way  through  the  FTX  was 
too  late. 

o  Discussion  was  focused  on  understanding  processes  and  not  on  improving  it. 

•  Operator  confusion  at  ANZAC  and  at  the  Coalition  Cell  was  high,  which  lead  to  lengthy 
chat  and  VoIP  communications  for  clarification. 

The  lack  of  SOPs  for  the  fires  coordination  process,  together  with  the  continued  presence  and 
efforts  to  resolve  ADOCS  integration  issues  essentially  undermined  all  unit  and  higher-level 
training.  The  result  was  the  on-going  confusion  experienced  by  the  Coalition  team  in  the  fires 
coordination  process. 
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FBE-Kilo,  Field  Training  Exercise  Phase 
Coalition  #3  -  ADOCS  and  RMG 


•  Full  integration  of  ADOCS  across  RMG  not  achieved. 

o  ANZAC  GISRC  nominations  not  found  in  FBE  ADOCS. 
o  Nominations  forwarded  by  IRC  Chat. 

•  ADOCS  and  RMG  protocols  incompatible. 


The  RMG  and  ANZAC  ADOCS  interface  apparently  had  problems. 

•  The  ANZAC  ADOCS  operators  attributed  coordination  blocks  defaulting  to  white  to 
RMG. 

o  Resulted  in  ANZAC  transmitting,  by  IRC,  to  the  Blue  Ridge  desired  coordination 
block  actions  that  were  inserted  in  the  ANZ  coordination  block  by  a  Blue  Ridge 
ADOCS  operator. 

•  No  ANZAC  GISRC  target  nominations  were  found  in  the  ADOCS  FBE  net  servers. 
ANZAC  GISRC  target  nominations  were  made. 

o  The  reason  why  these  nominations  were  not  seen  in  the  FBE  net  ADOCS  is 
unknown. 

Although  the  majority  of  ADOCS  problems  noted  during  the  final  OSD  testing  were  resolved, 
other  issues  became  apparent  during  experiment  execution. 

•  Full  integration  of  ADOCS  across  the  boundary  between  the  SECRET  US  NOFORN  and 
SECRET  AUSCANUKUS  releasable  networks  was  not  achieved. 

o  Delays  in  the  updates  to  Coalition  ADOCS  from  Blue  Ridge  were  unacceptable. 

•  Post  experiment  review  of  the  network  architecture  revealed  the  cause  of  the  update 
delays  to  be  a  constraint  in  the  ADOCS  server  network  and  the  underlying  protocol  used 
for  ADOCS  communications 
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FBE-Kilo,  Field  Training  Exercise  Phase 
Fires  #1  -TES-N 

•  Powerful  system  of  potential  great  use  for  Navy  TST. 

•  Developmental^  immature. 

o  Limited  interfaces  to  other  TST  C4I  systems, 
o  Handling  of  ISR  video  and  platform  sensor  telemetry, 

o  SCI  analysis  tools  and  SCI  to  GENSER  connectivity. 

•  System  improvements  required  before  further  experimentation. 


FBE-K  demonstrated  that  TES-N  has  a  number  of  powerful  tools  (some  of  which  are  unique  to 
TES-N)  that  potentially  could  be  of  great  use  to  Naval  forces  involved  in  Time  Sensitive 
Targeting  (TST).  Unfortunately,  FBE-K  reconfirmed  that  TES-N  remains  a  very  complex  and 
developmentally  immature  system,  with  extremely  limited  interfaces  to  other  C4I  systems  that 
are  critical  to  TST.  Major  advances  are  needed  for  the  following: 

•  Interface  with  ADOCS  or  other  TST  Command  and  Control  system 

•  Interface  with  GCCS-M 

•  Interface  to  PTW  and  any  external  target  folder  applications 

•  Handling  of  ISR  video  and  platform/sensor  telemetry 

SCI  COMINT  analysis  tools  and  SCI-to-GENSER  connectivity  via  ISSE  Guard 

The  presented  target  detection  and  identification  problem  from  simulated  video  was 
unsatisfactory  and  unrealistic  due  both  to  the  nature  of  the  simulated  imagery  and  TES-N 
processing  of  the  imagery.  This  is  an  equipment  problem  identified  elsewhere,  but  it  also 
indicates  the  need  for  additional  human  factor  engineering  so  that  efficient  usage  of  imagery  can 
occur.  Specific  problems  include: 

•  Video  quality  was  poor  and  the  displayed  target  coordinates  could  not  be  read 

•  The  chipped  images  were  of  low  resolution  and  unsuitable  for  georefinement. 

•  TES-N  could  not  process  the  telemetry  data  that  accompanied  the  imagery.  This  slowed 
and  complicated  the  target  nomination  process. 

TES-N  shouldn’t  be  used  in  further  TST  experimentation  until  improvements  are  made  in  the 
above  areas.  In  its  present  state  of  development,  experimentation  results  focus  on  system  needs 
rather  than  TST  process. 
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Fires  #2  -  ADOCS  for  TST  C2 

•  Extensive  input/output  typing  cumbersome. 

o  Need  an  AEGIS  or  AW  ACS  type  methodology. 

•  Target  prioritization  scheme  needed. 

•  Pending  actions  notification  needed. 

•  Currently  inadequate  for  TST 


Systems  engineering  of  a  TST  C2  System  should  look  beyond  the  extensive  typing  input-output 
approach  in  ADOCS,  and  its  matrix  displays,  for  TST  coordination  status.  It  became  apparent 
during  FBE-K  that  many  of  the  C2  processes  in  ADOCS  are  complicated,  difficult  to  define 
unambiguously,  challenging  to  train  to,  and  highly  dependent  on  internet  chat  and  voice 
elaboration.  FBE-K  raised  the  question  if  the  ADOCS  approach  is  the  right  concept  to  be 
applied  to  Joint  TST.  Some  of  the  functionality  built  into  air  defense  command  and  control 
systems,  such  as  AEGIS  or  AWACS  should  be  examined  for  applicability  to  ground  TSTs. 

The  TST  C2  System  needs  a  TST  prioritization  scheme  that  takes  into  account  both  the 
importance  of  the  target  and  the  amount  of  time  that  it  will  be  available  for  engagement.  There 
is  a  non-mandatory  block  in  ADOCS  for  target  priority.  Some  units  made  their  own  inputs  there. 
Most  didn’t.  There  are  static  priority  categories  listed  in  the  CJTF  TST  matrix,  but  those 
numbers  don’t  take  into  account  the  amount  of  time  available  to  engage  the  target. 

The  TST  C2  System  needs  to  explicitly  tell  operators  which  tasks  are  theirs  to  perform  and  their 
priority.  The  ADOCS  approach  of  one  big  table  for  MISSION  FIRES  COORDINATION  and 
one  big  table  for  the  JOINT  TIME  SENSITIVE  TARGETS  MISSIONS  is  not  well  engineered 
for  people  performing  required  tasks. 

•  JFMCC,  the  JFACC,  the  JFACC  TST  cell,  X-Ray  Papa,  and  others  need  to  distinguish 
which  targets  on  the  list  are  their  responsibility  and  which  are  someone  else’s. 

•  They  also  need  to  see  if  there  is  some  action  for  them  to  take. 

•  They  have  no  list  of  pending  actions. 

•  There  is  no  prioritization  of  actions  waiting  to  be  performed. 
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Fires  #3  -  Common  Operational  Picture 

•  All  M&S  produced  assets  displayed  in  GCCS-M,  first  time  achieved. 

•  TES-N  could  not  output  to  GCCS-M. 

•  GCCS-M  to  TES-N  tracks  appeared,  but  with  no  labels. 

•  COP  not  maintained  as  required  to  support  ISR  and  JFN  for  TST. 

o  Different  pictures  always  existed  in  GCCS-M,  ADOCS,  TES-N. 


By  the  end  of  FTX,  all  of  the  simulated  Blue  ISR  assets  active  in  M&S  were  simultaneously 
displayed  on  BLR’s  GCCS-M  COP  with  appropriate  labels  (e.g.,  two  ISR  UUVs,  two  Predator 
UAVs,  one  U-2).  This  was  the  first  time  that  this  has  happened  in  an  FBE. 

Manual  Contacts  were  to  be  transferred  to  GCCS-M  for  “tracking”  and  SA.  The  objective  was 
for  the  TST  nomination  analyst  to  not  only  create  an  ATI.ATR,  but  to  then  use  TES-N’s 
rudimentary  interface  to  GCCS-M  to  input  the  target  into  the  COP  as  a  track,  for  the  situational 
awareness  of  ALCON,  and  to  assist  (theoretically)  in  the  “tracking”  of  the  TST  while  waiting  for 
it  to  be  engaged. 

•  The  TES-N  output  to  GCCS-M  only  worked  for  two  days  only,  and  at  the  same 
rudimentary  and  suboptimal  level  at  which  it  was  working  for  MC02/FBE-J. 

•  Even  with  the  new  TES-N  version  5.0,  there  was  no  improvement  in  TES-N’s  ability  to 
output  to  GCCS-M  from  what  was  used  in  MC02/FBE-J. 

In  addition  to  TES-N’s  rudimentary  capability  to  send  “Manual  Contacts”  to  GCCS-M,  COP 
tracks  can  also  be  sent  from  GCCS-M  to  TES-N.  The  objective  of  attempting  to  do  so  was  to 
provide  a  richer  context  of  contacts,  tracks,  Blue  ISR  asset  locations,  etc.,  in  TES-N  for  the 
analysts  trying  to  find  and  fix  TSTs. 

•  TES-N’s  incoming  “Message  and  Data  Log”  showed  a  good  number  of  incoming  tracks 
from  GCCS-M,  but  those  tracks  did  not  appear  to  be  parsing  into  the  TES-N  ITD. 

•  When  GCCS-M  tracks  coming  into  TES-N  were  able  to  be  brought  up  on  the  ITD  they 
appeared  in  their  proper  locations  but  the  symbols  do  not  have  any  labels  associated  with 
them  (e.g.,  no  track  names),  making  them  all  but  functionally  useless  to  the  TST  team. 

Post-experiment  analysis  of  logged  data  showed  that  different  information  appeared  in  GCCS-M, 
ADOCS,  and  TES-N.  In  effect,  this  means  there  was  never  a  “Common”  Operational  Picture. 
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Fires  #4  -  ADOCS  Managers 

•  ADOCS  managers  have  inconsistencies  and  latencies, 
o  Inhibit  and  defeat  TST  engagement  process. 

o  Some  events  missing  from  histories. 

•  Consistent  color  coding  system  needed. 


The  ADOCS  Managers  exhibit  inconsistencies  and  latencies  that  at  times  inhibit  and 
occasionally  defeat  the  TST  engagement  process.  Specific  problems  observed  include: 

•  Missions  appear  in  some  ADOCS  workstations  but  not  others. 

•  The  coordination  block  status  can  be  different  at  different  ADOCS  workstations. 

•  The  mission  status  (e.g.  fired  or  not  fired)  may  be  different  in  the  Mission  Coordination: 
Fires  and  JTST  Managers.  For  the  JFMCC/XP  the  ADOCS  Mission  Coordination:  Fires 
Manager  is  the  primary  tool  for  prosecution  of  TSTs.  The  JTST  Manager  is  a 
collaboration  tool  to  provide  TST  situational  awareness  to  all  Components. 

•  The  Mission  Coordination:  Fires  and  JTST  Mission  Histories  can  be  inconsistent. 

•  Mission  status  as  detennined  from  the  Mission  History  may  not  agree  with  the  status  in 
the  Mission  Coordination:  Fires  display. 

•  Some  events  are  missing  from  the  Mission  Histories. 

•  There  are  multiple  examples  in  the  Mission  Histories  of  coordination  blocks  being 
changed  from  colors  that  they  do  not  hold.  Two  possible  explanations  for  this  are:  there 
are  events  changing  the  block  status  that  are  missing  from  the  Mission  History  log  or  the 
changes  implemented  at  one  ADOCS  workstation  were  not  received  at  a  second 
workstation  that  subsequently  acted  on  the  block  status. 

For  time-critical  tasks,  the  TST  C2  System  color-coding  should  be  standardized  and  intuitive  so 
that  operators  will  respond  predictably  and  quickly.  Color-coding  is  critical  to  using  ADOCS  as 
a  coordination  tool.  Operators  ended  up  inventing  a  color  scheme  for  FBE-K,  which  is  non¬ 
standard  because  there  are  no  standards.  This  isn’t  merely  a  training  or  doctrine  issue.  Because 
color-coding  is  being  used  for  coordination  of  time-critical  tasks,  the  colors  or  symbols  used 
should  be  engineered  to  be  much  more  intuitive  than  they  are.  Ideally,  as  intuitive  as  real  traffic 
lights  so  that  people  will  respond  predictably,  and  quickly. 
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Fires  #5  -  Fires  TTP 

•  Frequent,  and  serious  departures  from  Fires  TTP. 
o  Player  confusion, 

o  ADOCS  latencies  and  inconsistencies, 

o  TES-N  operators  lack  of  training. 


Frequent  and  serious  departures  from  the  Fires  TTP  were,  in  part,  stimulated  by  player  confusion 
or  misunderstanding  regarding  procedures  and  by  the  ADOCS  displays  latencies  and 
inconsistencies.  Departures  of  the  following  nature  were  observed  in  ADOCS  coordination 
block  actions: 

•  Required  TTP  actions  were  not  taken. 

•  Actions  taken  but  not  by  the  responsible  node. 

•  Actions  taken  that  are  undefined  by  the  TTP  and  hence  meaningless. 

•  Actions  executed  in  the  wrong  sequence. 

•  Actions  executed  in  such  a  way  as  to  indicate  that  the  actions  were  taken  to  force  the 
engagement  to  a  conclusion  rather  than  as  a  result  of  a  realistic  response  to  the  simulated 
engagement. 
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TST  Organization 

•  Xray  Papa  good  organization  for  TST  Afloat  testing, 
o  Adaptation  of  Air  Force  TCT. 

o  Maritime  targeting  gap  identified, 

o  Staff  function  at  the  JFMCC  level  required. 


The  Xray  Papa  cell  was  an  excellent  test  case  for  familiarization  of  the  Time  Critical  Targeting 
Functionality  (TCTF)  Afloat  concept  to  the  fleet.  TCTF  is  a  USAF  program  that  outlines  the  C2 
requirements  and  systems  for  conducting  TCT  operations.  In  support  of  JCC  and  JCC  (Afloat), 
the  USN  needs  to  further  refine  this  concept  to  support  both  joint  and  maritime  forces  from  a  flag 
configured  platform.  TCTF  Afloat  should  be  used  as  a  starting  point  for  future  Sea  Strike 
initiatives. 

The  Xray  Papa  cell  identified  a  time  sensitive  targeting  gap  at  the  maritime  component  level  that 
needs  to  be  addressed.  JFMCC’s  conduct  of  broad  scale  TST  operations  that  are  integrated  with 
other  components  is  beyond  the  traditional  role  of  the  Bravo  Papa.  A  staff  function  at  the 
operational  level  (JFMCC)  that  supports  TST  prosecution  is  required.  Experimentation  should 
integrate  this  development  with  the  TCTF  effort  described  above  to  help  identify  maritime  TST 
command  and  control  requirements  of  the  future. 
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FBE  Data 

•  Less  electronic  data  was  available  than  in  other  FBEs. 

o  No  TES-N,  GISRC,  or  PTW  data  produced  for  FTX. 

•  Cannot  develop  TST  workflow. 

o  Only  9  of  29  required  data  elements  produced. 

•  Objective  data  requirements  program  necessary  for  experiment  success, 
o  Mandatory  requirements  and  funding  necessary. 


Compared  to  other  recent  FBEs  the  objective  data  provided  for  this  experiment  was  deficient  in 
quantity  and  quality.  In  particular: 

•  The  provided  TES-N  covered  only  a  few  days  of  the  CPX  and  was  reformatted  so  as  to 
be  unusable. 

•  No  GISRC  data  were  provided. 

•  The  ADOCS  JTST  manager  did  not  set  capture  mission  histories  for  the  last  two  days  of 
the  experiment 

•  After  acquiring  excellent  mensuration  data  from  RRF  in  FBE-J,  FBE-K  reverted  to  PTW 
which  has  never  provided  usable  data. 

•  The  JSAF  event  data  logged  in  SNN  did  not  include  Fire  events.  There  were  gaps  in  the 
JSAF  event  data  and/or  many  fire  commands  did  not  reach  JSAF. 

If  workflow  or  timelines  are  to  be  a  part  of  evaluating  TST  capabilities,  adequate  electronic  data 
must  be  available  from  all  systems  that  are  part  of  the  TST  process,  including  simulations. 
Application  of  the  following  measures  would  do  much  to  improve  the  collected  objective  data: 

1 .  Require  for  system  participation  in  an  experiment  that  the  system  incorporate  tools  that 
log,  identify  and  timestamp  all  significant  operator  actions. 

2.  Require  data  logging  in  formats  that  can  be  easily  manipulated  for  analysis. 

3.  Include  as  an  objective  in  pre-experiment  integration  testing  the  validation  of  the  data 
logging  applications. 

Such  a  program  will  require  funding  be  provided  to  system  “owners”. 

•  Provide  the  funding  needed  for  the  data  capture  program. 
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Technology  #1  -  Shipboard  Systems 


•  Incompatibilities  existed  between  shipboard  systems  and  ADOCS 
o  Backbone  characteristics, 
o  Inconsistent  network  card  settings. 


Need  to  establish  LAN  configurations  that  support  ADOCS. 
o  Switch, 

o  Link. 

o  Network  card  settings. 


USS  Blue  Ridge  has  a  10  mb  switch  backbone  that  is  connected  via  155  mb  links.  This,  along 
with  inconsistent  network  card  setting  hindered  ADOCS  use  during  the  FBE.  Standard, 
shipboard  LAN  configurations  that  support  ADOCS  need  to  be  established.  This  applies  to 
switch,  link,  and  network  card  settings  on  these  machines.  Hardware  limitations  may  require 
platforms  to  set  up  multi-server  configurations  to  reduce  the  effect  of  less  modern  network 
backbones.  ISNS  ADOCS  standards  need  to  be  set  prior  to  an  experiment  install  and  configured 
accordingly. 
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Technology  #2  -  ADOCS  Recommendations 

•  Improvements  needed  to  support  C2  requirements. 

•  ADOCS  software  changes. 

o  User  interfaces, 
o  Alerting. 

o  Links  to  other  information, 
o  ATI.ATR  messages. 


Many  recommended  changes  to  ADOCS  were  compiled  during  the  FBE.  ADOCS  changes  are 
indicative  of  command  and  control  capability  requirements  that  currently  exist.  Software 
improvements  are  needed  for: 

1 .  Ability  to  pair  a  target  to  an  ITO  mission  via  a  button 

2.  Ability  to  highlight  targets  in  Fires  and  JTST  Managers  when  changes  have 

occurred...  alert? 

3.  A  configurable  Fires  Manager  (within  the  ADOCS  GUI). 

4.  Add  “hour  glass”  icon  to  ADOCS  to  display  system  working. 

5.  TST  supported  CDR  indicator  in  JTST  Manager. 

6.  Hot  link  to  ROE  url. 

7.  Hot  link  to  TST  priorities  url. 

8.  Creation  of  a  Combat  Assessment  Manager  and  removal  of  that  function  from  the 

Fires/JTST  managers. 

9.  Hot  link  to  target  folder  url. 

Hardware 

1.  Two  (2)  displays  for  ADOCS  users  that  are  doing  target  development  and 

coordination 

ATI.ATR  target  nomination  to  between  TES-N  and  ADOCS  was  incomplete  and  not  viable  for 
usage.  Inconsistencies  existed  in  how  target  nominations  were  handled  by  ADOCS  and  how 
they  were  showing  up  in  the  TST  Target  Folder  server.  The  fault  was  in  both  TES-N  and 
ADOCS,  with  inconsistencies  in  target  line  usage.  ADOCS  turned  around  an  ATI.ATR  with 
fields  out  of  order  and  truncated.  This  problem  needs  to  be  fixed.  It  was  identified  over  2  years 
ago  and  is  still  a  problem.  This  should  be  completed  in  the  lab  rather  than  waiting  for  another 
experiment. 
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Technology  #3  -  JFN  Recommendations 

•  JFN  had  mixed  success  supporting  TST  operations, 
o  ELINT  mixed  success, 
o  COMINT  unsuccessful, 
o  Cross-INT  limited  success. 


ELINT/ESM  was  sent  from  various  M&S  sources  to  the  TDDS  Network  Management  Center,  to 
be  put  onto  the  TDDS  broadcast,  with  receipt  of  the  broadcast  on  BLR  via  organic  means,  and 
processing  of  exercise/experiment  ELINT  using  the  GALE  software  in  TES-N. 

•  Successful  receipt  was  achieved 

•  TES-N  GALE  was  unable  to  receive,  process,  and  display  TACELINT  messages  from 
ISR  UUV  that  reported  an  LOB. 

COMINT  injects  were  sent  via  SI  broadcast  to  BLR  and  received  by  a  COMINT  analyst  using 
TES-N. 

•  COMINT  injects  were  received  only  on  SCI  GCCS-M,  as  that  is  the  way  the  BLR  SCI 
architecture  was  configured. 

•  The  COMINT  analyst  at  the  SCI  GCCS-M  received  the  injects  as  emails,  printed  them, 
and  sneaker-netted  them  to  the  TST  team  manning  TES-N  terminals. 

•  TES-N  does  not  have  any  true  COMINT  analysis  tools  (as  does  SCI  GCCS-M). 

•  TES-N  Information  Support  Server  Environment  Guard  was  non-functional  on  BLR. 

Replication  of  TES-N’s  Cross-INT  database  was  attempted  to  both  ISRM  (CPX)  and  the  ESX 
RTC  (FTX),  but  with  very  limited  success. 

•  During  CPX,  Cross-INT  was  not  replicated  to  ISRM  due  to  ISRM  instability  problems. 

•  During  FTX,  Cross-INT  was  replicated  to  ESX  RTC. 

•  Target  Nominations  created  in  TES-N  are  not  replicated  to  ISRM  /  RTC. 
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Technology  #4  -  JFN  Recommendations  2 

•  JFN 

had  mixed  success  supporting  TST  operations. 

o 

Target  nomination  messages. 

o 

Image  management. 

o 

File  transfers. 

The  TST  nomination  analyst  used  TES-N  to  create  a  target  nomination  message  (in  USMTF 
“ATI.ATR”  format),  and  to  send  that  nomination  message  (via  SMTP)  to  the  ADOCS  server  on 
BLR,  and  to  the  TST  Target  Folder  server  at  NWDC.  Considerable  effort  was  required  to  get  all 
systems  interoperating  correctly,  TES-N  LAN,  ship’s  LAN/Exchange  server,  FBE-K  WAN  and 
Exchange  servers,  ADOCS  mail  server.  Once  set  up  properly  the  process  worked  well. 

The  objective  was  to  attach  images  (e.g.,  video  “chips”  showing  the  TST)  to  the  outgoing  target 
nomination  for  aim-point  refinement,  and  the  nomination  sent  simultaneously  to  ADOCS,  TST 
Target  Folder,  and  PTW. 

•  The  version  of  PTW  used  on  BLR  could  not  receive  and  parse  ATI.ATR  messages  (i.e., 
did  not  have  the  DTMS  software  used  in  MC02/FBE-J). 

•  TES-N  does  not  allow  images  to  be  attached  to  outgoing  ATI.ATRs. 

•  All  images  captured,  chipped,  and  saved  (as  NITF)  in  TES-N  had  to  be  manually 
transferred  (FTP)  to  PTW. 

•  The  PTW  operator  would  pull  up  the  images  and  conduct  aimpoint  refinement,  then  save 
the  images  (as  both  JPEG  and  NITF)  to  a  shared  directory  on  the  BLR  IT-21  LAN. 

The  TST  nomination  analyst  was  to  attach  images  to  the  outgoing  target  nomination  so  that  the 
TST  Target  Folder  server  could  add  the  image(s)  to  the  TST’s  target  folder. 

•  TST  Target  Folder  server  worked  well  and  the  NWDC  TST  Target  Folder  server 
application  proved  to  be  a  simple  but  powerful  prototype. 

•  The  new  version  5.0  of  TES-N  software  still  cannot  attach  images  to  ATI.ATRs. 

Because  “DIOP”  is  only  for  the  transfer  of  U-2  imagery  that  is  being  (or  has  just  been)  directly 
downlinked,  other  file  types  must  be  exchanged  between  TES-N  and  remotes  like  ISRM  and 
RTCs  using  standard  means  such  as  FTP  and  SMTP. 

•  FTP  and  SMTP  worked  well. 

•  RTC  Lites  worked,  with  varying  difficulty.  RTC  Lite  at  NUWC  was  fairly  easy  to  get 
up,  configuring  the  others  was  difficult. 
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CPX  PR#2  -  Achievement  of  JFN  Contributions  to  TST  Objective 

•  No  baseline  without  JFN  available,  cannot  perform  an  adequate  test. 

•  Equipment  difficulties  prevented  adequate  testing  of  JFN  capabilities, 

o  Lack  of  TES-N  to  ADOCS  connectivity. 

o  Failure  of  FBEnet. 

•  Only  TES-N  in  the  JIC  was  tested. 


The  stated  JFN  objective  was  to  determine  the  contribution  of  JFN  to  TST  prosecution.  In  order 
to  determine  JFN-unique  contributions,  or  synergistic  JFN  effects,  a  baseline  of  perfonnance 
without  JFN  is  needed.  Such  a  baseline  requires  using  the  same  C2  structure  and  infonnation 
processes  as  were  used  in  the  experiment.  Baseline  infonnation  is  not  available. 

Equipment  problems  prevented  testing  end-to-end  JFN  performance.  Target  nominations  could 
not  be  passed  directly  from  TES-N  to  ADOCS,  or  directly  to  ISRM.  FBEnet  was  not  operational 
due  to  Ku  Band  switching  problems  in  Hawaii.  The  result  was  that  many  information  paths  that 
are  crucial  for  realizing  JFN  potential  were  not  operational. 

Because  of  the  collection  of  equipment  and  manning  problems  the  only  comprehensive  test  of 
JFN  that  could  be  made  was  of  the  TES-N  component  in  the  JIC. 

The  basic  objectives  of  this  initiative  could  not  be  met.  Results  that  could  be  derived  are 
indications  of  JFN  potential  for  TST  processes  within  a  JIC. 


no 


FBE-Kilo,  CPX 

CPX  PR#3  -  TES-N  Capabilities 

•  Works  well  for  IMINT  exploitation. 

o  Video  screener  a  major  factor  in  closing  TST  timeline, 
o  Directing  tactical  imagery  assets. 

•  Inability  to  drop  validated  aim  points  a  major  drawback. 

•  Improved  sensor  control  by  image  analyst  required. 


Image  analysis  and  processing  worked  well,  essentially  creating/producing  an  efficient  assembly 
line.  Operators,  with  little  training,  were  able  to  explore  images  and  make  both  analysis  and 
processing  decisions  fairly  quickly.  (Difficulties  encountered  because  of  the  simulation  are 
covered  in  a  subsequent  Principal  Result  (in  CPX  Report).) 

An  important  capability  was  for  the  image  analyst  to  be  able  to  direct  tactical  sensors.  The 
analyst  worked  through  a  sensor  manager  and  the  process  worked  moderately  well.  There  were 
difficulties  with  this  sensor  control,  as  implemented,  in  that  there  was  no  direct  provision  for 
sensor  control  at  the  analyst's  terminal.  A  direct  link  that  the  analyst  can  use  without 
interrupting,  nor  losing  sight  of,  imagery  is  needed. 

There  were  problems  with  imagery  infonnation  content.  Transmission  of  aim  points  and  Lat- 
Long  needs  to  be  improved.  This  was  done  verbally  or  by  notes,  which  slowed  the  process. 


Ill 


FBE-Kilo,  CPX 

CPX  PR#5  -  Operator’s  Acceptance  of  TES-N 

•  In  spite  of  lack  of  familiarity,  operators  recognized  the  system’s  potential 
for  improving  performance  and  efficiency 

•  User-friendly  and  easy  to  leam. 

•  Much  appreciation  of  several  functions  combined  in  one  machine. 


With  the  exception  of  the  team  leader,  the  TES-N  operators  were  totally  unfamiliar  with  the 
system  and  with  TST  processes.  Their  training  was  on  IPB  processes.  Thus,  they  were  being 
introduced  to  both  a  new  system  and  a  new  process.  In  spite  of  this  they  were  enthusiastic  about 


TES-N. 


They  felt  the  system  was  easy  to  learn  and  that  the  graphical  user  interface  (GUI)  layout  and 
methods  of  use  were  fairly  intuitive. 

The  system  layout  was  such  that  a  terminal  could  be  used  for  image  screening,  image  analysis,  or 
nomination.  This  allowed  those  operations  to  be  exchanged  or  shared.  Having  multiple 
functions  resident  within  one  machine  produced  manpower  savings  as  a  result  of  increased  work 
efficiency  and  direct  sharing  of  information  between  operators. 
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FBE-Kilo,  CPX 

CPX  PR#6  -  TES-N  Training  Issues 

•  Current  simulation  hinders  training. 

o  Lack  of  reality  interfered  with  all  aspects  of  training  and  performance, 
o  Simulation  designed  specifically  for  TES-N  training  needed. 

•  Operators  need  broad  TST  process  training. 


CPX  was  used  to  provide  TES-N  operator  training  in  an  operational  context.  But,  the  simulation 
used  for  the  experiment  presented  unrealistic  renderings  of  battlefield  objects.  This  lack  of 
realism  interfered  with  operator  performance  and  therefore  with  their  training.  In  addition  to  low 
fidelity,  the  presentation  of  the  battlefield  was  such  that  image  analysts  could  not  distinguish 
different  instances  of  the  same  object  type.  This  produced  a  situation  where  operators  were 
moving  back  and  forth  between  objects  to  figure  out  which  was  which,  interfering  with  training. 


A  realistic  simulation  designed  specifically  for  TES-N  training  is  needed. 

Operators  did  not  have  an  understanding  of  the  TST  process.  Training  on  the  TST  process  was 
being  conducted  at  the  same  time  as  how  to  do  it.  Training  on  the  full  TST  process  is  needed  as 
a  prerequisite  to  system  "knobology"  training. 
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FBE-Kilo,  CPX 

CPX  Recommendation  H2.5  -  Experiment  Planning  Stability 

•  Last  minute  changes  interfere  with  experiment  execution, 
o  Addition  of  equipment. 

o  Process  modification  or  changes. 

•  Lock-down  date  for  experiment  plans  needed. 


This  principal  finding  is  derived  from  the  CPX  recommendation  in  this  reports  Section  H2.5. 

CPX  was  an  unusual  situation  in  that  there  were  major  changes  in  the  experiment  structure  (e.g. 
lack  of  a  JFACC  Forward)  shortly  before  the  experiment,  and  then  personnel  shortfalls  due  to 
BLUE  RIDGE  departing  early  for  the  typhoon.  However,  it  is  not  unusual  in  FBEs  to  have 
equipment  and  process  changes  occur  right  up  to  the  beginning  of  an  experiment.  Such  changes 
have  many  effects,  such  as: 

Disrupt  data  capture  and  analysis  plans. 

Prevent  capturing  data  required  to  meet  Initiative  objectives. 

Cannot  provide  adequate  training  on  added  systems  and  processes. 

Cannot  adequately  test  added  systems. 

It  is  recommended  that  an  experiment  be  "locked  down"  four  months  prior  to  its  start.  An 
exception  would  be  when  there  is  a  series  of  events  that  includes  an  equipment  testing  LOE  prior 
to  the  field  experiment.  In  this  case,  the  LOE  should  occur  six  weeks  prior  to  the  operational 
experiment  and  the  lock-down  occur  within  one  week  after  the  LOE. 
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6.3  COALITION  INITIATIVE  FINDINGS  AND  INSIGHTS 


Radiant  Mercury  Guard  (RMG)  is  a  network  security  tool  that  was  employed  as  a  message  filter 
between  U.S.  and  Australian  classified  networks  during  FBE-Kilo.  RMG  scans  message  headers 
for  key  words  and  filters  (does  not  pass)  messages  that  contain  infonnation  deemed  inappropriate 
by  a  predetermined  rule  set.  If  RMG  does  not  recognize  a  message  type,  it  will  not  be  passed. 


6.3.1  ADOCS  Network  Messages 

The  ADOCS  network,  as  deployed  during  FBE-Kilo,  included  the  capability  to  generate  and 
exchange  prototype  messages  that  could  not  be  recognized  by  RMG.  This  was  a  known 
condition  at  the  outset  of  the  experiment.  It  was  very  detrimental  to  the  objectives  of  the 
Initiative  as  it  hampered  both  Fires  process  development  and  demonstration  of  Coalition  Fires 
participation. 


6.3.2  Coalition  Fires  TTP 

The  most  significant  issue  encountered  by  Coalition  was  the  absence  of  a  clearly  defined, 
tactical  level,  step-by-step  process  for  the  command  and  control  coordination  of  fires. 

•  Creation  of  a  step-by-step  process  for  fires  coordination  part  way  through  the  FTX  was 
too  late. 

o  Discussion  was  focused  on  understanding  processes  and  not  on  improving  it. 

•  Operator  confusion  at  ANZAC  and  at  the  Coalition  Cell  was  high,  which  lead  to  lengthy 
chat  and  VoIP  communications  for  clarification. 

The  lack  of  SOPs  for  the  fires  coordination  process,  together  with  the  continued  presence  and 
efforts  to  resolve  ADOCS  integration  issues  essentially  undennined  all  unit  and  higher-level 
training.  The  result  was  the  on-going  confusion  experienced  by  the  Coalition  team  in  the  fires 
coordination  process. 


6.3.3  ADOCS  Integration 

Although  the  majority  of  ADOCS  problems  noted  during  the  final  OSD  testing  were  resolved, 
other  issues  became  apparent  during  experiment  execution. 

•  Full  integration  of  ADOCS  across  the  boundary  between  the  SECRET  US  NOFORN  and 
SECRET  AUSCANUKUS  releasable  networks  was  not  achieved. 

o  Delays  in  the  updates  to  Coalition  ADOCS  from  Blue  Ridge  were  unacceptable. 

•  Post  experiment  review  of  the  network  architecture  revealed  the  cause  of  the  update 
delays  to  be  a  constraint  in  the  ADOCS  server  network  and  the  underlying  protocol  used 
for  ADOCS  communications 
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6.3.4  RMG  Rule  Set 


RMG  bridged  the  security  boundary  between  the  SECRET  US  NOFORN  and  SECRET 
AUSCANUKUS  releasable  networks.  Due  to  budget  and  time  constraints  for  accreditation  of 
RMG,  a  previously  approved  rule  set  was  used. 

•  This  rule  set  did  not  use  the  latest  message  format  used  in  ADOCS. 

o  Not  all  of  the  data  sent  through  RMG  from  SECRET  US  NOFORN  ADOCS  was 
transferred  to  the  Coalition  network. 

•  GCCS-M  COP  was  transmitted  effectively  across  RMG. 

6.3.5  Chat,  VoIP,  and  Sneaker-Net 

Radiant  Mercury  Guard  was  used  to  filter  and  transfer  structured  messages  for  FBE-K.  To 
exchange  unstructured  messages  (Chat,  e-mail,  VoIP,  web  pages)  between  U.S.  and  Coalition 
systems,  a  human-in-the-loop  ‘air  gap’  (Sneaker-Net)  was  utilized.  Information  from  U.S.  was 
reviewed  and  relevant  information  for  Coalition  was  transferred  across  the  boundary. 

•  Utilized  due  to  the  lengthy  approval  process  for  an  automatic  filtering  system. 

•  Using  Sneaker-Net,  a  direct  transfer  of  chat  messages  was  not  maintained. 

•  Delay  in  message  transfer  was  not  the  major  issue  for  this  system. 

•  E-mail  volume  did  not  increase  the  delay  of  chat  message  transfer. 

Transcribing  messages  between  the  XP  cell  on  Blue  Ridge  and  the  ANZAC  command  team  in 
Fem  Hill  led  to  some  ambiguity  in  communication. 

The  air  gap  between  the  Coalition  IRC  net  and  FBE  IRC  net  systems: 

•  Introduced  latencies  of  typically  about  seven  minutes. 

•  Was  manpower  intensive  to  pass  information  across  the  gap. 

•  An  automated  filter  (e.g.  ISSE  Guard)  is  required. 

VoIP  was  of  high  quality  after  network  issues  were  resolved. 

•  VoIP  was  effectively  utilized  for  technical  troubleshooting  and  demonstrated  a  potential 
for  use  in  tactical  coordination. 

The  transfer  of  web  page  information  was  complicated  and  a  significant  amount  of  time  was 
used  for  this  process. 

•  As  with  Chat,  the  reliance  on  web  portals  to  provide  access  to  infonnation  necessitates  a 
better  solution  to  the  problem  of  integrating  coalition  partners. 

6.3.6  Interface  Problems 

The  RMG  and  ANZAC  ADOCS  interface  apparently  had  problems. 

•  The  ANZAC  ADOCS  operators  attributed  coordination  blocks  defaulting  to  white  to 
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RMG. 

o  Resulted  in  ANZAC  transmitting,  by  IRC,  to  the  Blue  Ridge  desired  coordination 
block  actions  that  were  inserted  in  the  ANZ  coordination  block  by  a  Blue  Ridge 
ADOCS  operator. 

•  No  ANZAC  GISRC  target  nominations  were  found  in  the  ADOCS  FBE  net  servers. 
ANZAC  GISRC  target  nominations  were  made. 

o  The  reason  why  these  nominations  were  not  seen  in  the  FBE  net  ADOCS  is 
unknown. 


6.4  FIRES  INITIATIVES  FINDINGS  AND  INSIGHTS 

Findings  obtained  for  the  Fires  Initiatives  are  qualitative  rather  than  quantitative,  and  broad 
rather  than  specific.  FBE-Kilo  introduced  the  use  of  JFN,  including  TES-N,  to  Seventh  Fleet 
personnel.  Training  on  some  of  the  component  systems  was  conducted  and  Fleet  personnel 
acceptance  of  the  systems,  and  the  possibilities  they  presented  for  improved  operations,  was 
documented.  Indications  of  possible  TST  process  improvement  were  obtained  rather  than  a 
determination  of  what  process  and  system  use  does  and  does  not  work.  Definitive 
recommendations  for  needed  system  and  process  improvements  before  JFN  can  achieve  the 
needed  level  of  performance  for  TST  have  been  identified. 


6.4.1  System  Improvements 

FBE-Kilo  produced  a  significant  number  of  recommendations  for  system  improvement.  A 
number  of  these  had  already  been  identified  in  fonner  experiments.  Whether  confirming/ 
identifying  needed  improvements  justified  the  time  and  expense  of  this  FBE  is  an  unanswered 
question.  It  is  clear  that  doing  another  experiment  without  these  improvements  would  not  be 
justified. 

Recommendation :  Make  the  identified  JFN  system  improvements  before  conducting 
another  TST  field  experiment  with  this  system  and/or  its  components. 


6.4.2  Tactical  Exploitation  System  -  Navy 

Needed  Improvements  FBE-K  demonstrated  that  TES-N  has  a  number  of  powerful  tools  (some 
of  which  are  unique  to  TES-N)  that  potentially  could  be  of  great  use  to  Naval  forces  involved  in 
Time  Sensitive  Targeting  (TST).  Unfortunately,  FBE-K  reconfirmed  that  TES-N  remains  a  very 
complex  and  developmentally  immature  system,  with  extremely  limited  interfaces  to  other  C4I 
systems  that  are  critical  to  TST.  Major  advances  are  needed  for  the  following: 

•  Interface  with  ADOCS  or  other  TST  Command  and  Control  system 

•  Interface  with  GCCS-M 

•  Interface  to  PTW  and  any  external  target  folder  applications 

•  Handling  of  ISR  video  and  platform/sensor  telemetry 
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SCI  COMINT  analysis  tools  and  SCI-to-GENSER  connectivity  via  ISSE  Guard 


Target  Detection  and  ID  The  presented  target  detection  and  identification  problem  from 
simulated  video  was  unsatisfactory  and  unrealistic  due  both  to  the  nature  of  the  simulated 
imagery  and  TES-N  processing  of  the  imagery.  This  is  an  equipment  problem  identified 
elsewhere,  but  it  also  indicates  the  need  for  additional  human  factor  engineering  so  that  efficient 
usage  of  imagery  can  occur.  Specific  problems  include: 

•  Video  quality  was  poor  and  the  displayed  target  coordinates  could  not  be  read 

•  The  chipped  images  were  of  low  resolution  and  unsuitable  for  georefinement. 

•  TES-N  could  not  process  the  telemetry  data  that  accompanied  the  imagery.  This  slowed 
and  complicated  the  target  nomination  process. 

6.4.3  ADOCS  Managers 

The  ADOCS  Managers  exhibit  inconsistencies  and  latencies  that  at  times  inhibit  and 
occasionally  defeat  the  TST  engagement  process.  Specific  problems  observed  include: 

•  Missions  appear  in  some  ADOCS  workstations  but  not  others. 

•  The  coordination  block  status  can  be  different  at  different  ADOCS  workstations. 

•  The  mission  status  (e.g.  fired  or  not  fired)  may  be  different  in  the  Mission  Coordination: 
Fires  and  JTST  Managers.  For  the  JFMCC/XP  the  ADOCS  Mission  Coordination:  Fires 
Manager  is  the  primary  tool  for  prosecution  of  TSTs.  The  JTST  Manager  is  a 
collaboration  tool  to  provide  TST  situational  awareness  to  all  Components. 

•  The  Mission  Coordination:  Fires  and  JTST  Mission  Histories  can  be  inconsistent. 

•  Mission  status  as  detennined  from  the  Mission  History  may  not  agree  with  the  status  in 
the  Mission  Coordination:  Fires  display. 

•  Some  events  are  missing  from  the  Mission  Histories. 

•  There  are  multiple  examples  in  the  Mission  Histories  of  coordination  blocks  being 
changed  from  colors  that  they  do  not  hold.  Two  possible  explanations  for  this  are:  there 
are  events  changing  the  block  status  that  are  missing  from  the  Mission  History  log  or  the 
changes  implemented  at  one  ADOCS  workstation  were  not  received  at  a  second 
workstation  that  subsequently  acted  on  the  block  status. 

6.4.4  Fires  TTP 

Frequent  and  serious  departures  from  the  Fires  TTP  were,  in  part,  stimulated  by  player  confusion 
or  misunderstanding  regarding  procedures  and  by  the  ADOCS  displays  latencies  and 
inconsistencies.  Departures  of  the  following  nature  were  observed  in  ADOCS  coordination 
block  actions: 

•  Required  TTP  actions  were  not  taken. 

•  Actions  taken  but  not  by  the  responsible  node. 

•  Actions  taken  that  are  undefined  by  the  TTP  and  hence  meaningless. 
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•  Actions  executed  in  the  wrong  sequence. 

•  Actions  executed  in  such  a  way  as  to  indicate  that  the  actions  were  taken  to  force  the 
engagement  to  a  conclusion  rather  than  as  a  result  of  a  realistic  response  to  the  simulated 
engagement. 

6.4.5  Common  Operational  Picture 

A  common  operational  picture  is  non-existent.  In  FBE-K  a  COP  was  not  maintained  to  a  level 
required  to  support  ISR  and  JFN  in  support  of  TST.  Different  pictures  always  existed  in  GCCS- 
M,  ADOCS,  and  TES-N. 


6.4.6  ADOCS  as  the  TST  Command  and  Control  System 

Alternative  Approaches  to  Time  Sensitive  C2  Systems  engineering  of  a  TST  C2  System  should 
look  beyond  the  extensive  typing  input-output  approach  in  ADOCS,  and  its  matrix  displays,  for 
TST  coordination  status.  It  became  apparent  during  FBE-K  that  many  of  the  C2  processes  in 
ADOCS  are 

•  complicated, 

•  difficult  to  define  unambiguously, 

•  challenging  to  train  to,  and 

•  highly  dependent  on  internet  chat  and  voice  elaboration. 

ADOCS  is  an  Advanced  Concept  Technology  Demonstration  (ACTD),  but  the  challenges 
evident  in  FBE-K  raise  the  question  if  the  ADOCS  approach  is  the  right  concept  to  be  applied  to 
Joint  Time  Sensitive  Targeting.  Because  of  the  time-sensitivity  of  the  targets  and  because  it  is  at 
the  tactical  level  of  war,  some  of  the  functionality  built  into  air  defense  command  and  control 
systems,  such  as  AEGIS  or  AWACS  should  be  examined  for  applicability  to  ground  TSTs. 

Target  Prioritization  The  TST  C2  System  needs  a  TST  prioritization  scheme  that  takes  into 
account  both  the  importance  of  the  target  and  the  amount  of  time  that  it  will  be  available  for 
engagement.  There  is  a  non-mandatory  block  in  ADOCS  for  target  priority.  Some  units  made 
their  own  inputs  there.  Most  didn’t. 

•  Procedures  are  needed  for  who  is  supposed  to  enter  a  priority.  Most  important  are: 

•  What  does  the  priority  mean? 

•  How  is  it  to  be  detennined? 

There  are  static  priority  categories  listed  in  the  CJTF  TST  matrix,  but  those  numbers  don’t  take 
into  account  the  amount  of  time  available  to  engage  the  target. 

There  are  available  simple  mathematical  models  (fonnulas)  for  prioritization  based  on  both 
target  utility  and  probability  that  it  will  remain  engageable  for  some  period  of  time  (one  simple 
approach  looks  like  economic  discounting).  Target  prioritization  needs  to  be  addressed  in  TST 
command  and  control. 

Pending  Tasks  The  TST  C2  System  needs  to  explicitly  tell  operators  which  tasks  are  theirs  to 


119 


perform  and  their  priority.  The  ADOCS  approach  of  one  big  table  for  MISSION  FIRES 
COORDINATION  and  one  big  table  for  the  JOINT  TIME  SENSITIVE  TARGETS  MISSIONS 
is  not  well  engineered  for  people  performing  required  tasks. 

•  JFMCC,  the  JFACC,  the  JFACC  TST  cell,  X-Ray  Papa,  and  others  need  to  distinguish 
which  targets  on  the  list  are  their  responsibility  and  which  are  someone  else’s. 

o  This  requires  them  to  scan  the  list  doing  mental  vertical  sorting. 

•  They  also  need  to  see  if  there  is  some  action  for  them  to  take. 

o  This  requires  them  to  scan  the  table  doing  mental  horizontal  sorting. 

•  They  have  no  list  of  pending  actions. 

•  There  is  no  prioritization  of  actions  waiting  to  be  perfonned. 

TSTs  That  Move,  Re-Position,  and  Change  Status  The  TST  C2  System  needs  functionality  for 
automatically  and  unambiguously  keeping  track  of  targets  that  move,  re -position,  and  change 
status.  ADOCS  needs  functionality  added  for  targets  that  may  move  (allowing  a  track  number  to 
move  with  them  so  long  as  they  are  held  by  sensors),  i.e.,  dynamic  target  position  information 
rather  than  static  data  fields.  Concurrently  functionality  is  needed  for  automatic  updating  and 
alerting  of  decision  makers  and  engagers.  This  shouldn’t  rely  on  voice  or  chat  or  typed-in 
remarks. 

ADOCS  functionality  is  also  needed  for  other  critical  changes  in  target  status,  such  as  missiles 
transitioning  from  stowed  to  erected  positions.  This  may  require  dynamic  updating  of  target 
description,  and  certainly  needs  automatic  updating  and  alerting  of  decision  makers  and 
engagers. 

Human  Systems  Integration  for  Color-coding  For  time-critical  tasks,  the  TST  C2  System  color¬ 
coding  should  be  standardized  and  intuitive  so  that  operators  will  respond  predictably  and 
quickly.  Color-coding  is  critical  to  using  ADOCS  as  a  coordination  tool.  Operators  ended  up 
inventing  a  color  scheme  for  FBE-K,  which  is  non-standard  because  there  are  no  standards.  This 
isn’t  merely  a  training  or  doctrine  issue.  Because  color-coding  is  being  used  for  coordination  of 
time-critical  tasks,  the  colors  or  symbols  used  should  be  engineered  to  be  much  more  intuitive 
than  they  are.  Ideally,  as  intuitive  as  real  traffic  lights  so  that  people  will  respond  predictably, 
and  quickly. 

Human  Systems  Integration  for  Symbol-coding  For  time-critical  tasks,  the  TST  C2  System  use 
of  symbol-coding  to  supplement  color-coding  should  be  automated,  streamlined,  or  eliminated. 
The  coding  scheme  developed  for  ADOCS  blocks  includes  an  X  in  some  blocks  on  top  of  the 
color.  This  scheme  now  requires  two  distinctly  different  sets  of  actions,  one  to  set  the  color,  and 
another  sequence  of  actions  to  add  the  X  when  needed.  This  is  not  as  streamlined  and  error- 
resistant  as  a  time-critical  process  should  be. 

IRC  Chat  Entries  The  event  timeline  IRC  entries  sometimes  show  detailed  reporting  regarding 
the  color  block  changes  that  are  being  made  to  the  ADOCS  display.  This  is  attributable,  in  part, 
to  uncertainty  among  some  participants  about  the  TST  procedures  and,  in  part,  to  the  lack  of 
confidence  in  ADOCS  to  accurately  reflect,  in  a  timely  manner,  the  operator  block  actions  to  all 
ADOCS  workstations. 
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•  These  detailed  communications  result  in  an  expansion  of  the  engagement  timeline  and,  in 
effect,  make  ADOCS  redundant. 

•  All  the  coordination  actions  appear  to  be  occurring  in  chat  and  ADOCS  becomes 
unnecessary. 

Target  Georefinement  Target  georefinement  was  not  played  as  an  integral  part  of  this 
experiment.  In  previous  FBEs  ADOCS  was  the  tool  that  requested,  displayed  and  logged 
mission  georefinement  status.  This  function  of  ADOCS  was  not  a  component  of  Fires  play  in 
FBE-K. 


6.4.7  Equipment  Casualty  Modes 

The  TST  C2  System  needs  to  have  reliable  alternative  modes  of  operation  and  more  graceful 
degradation  than  is  currently  available  with  open-architecture  LANs  and  internet-style  networks. 
Most  legacy  combat  systems  have  casualty  modes.  Some  have  several  levels  of  casualty  modes. 
There  is  a  risk  that  the  down-time  and  network  problems  encountered  in  FBE-K  may  not  be 
atypical  of  what  might  occur  in  the  real  world  with  leading  edge  technologies,  pushing  the 
envelope,  built  on  open-architecture  machines  and  networks. 


6.5  DOTMLPF  IMPACTS 

No  DOTMLPF  impacts  can  be  deduced  from  this  experiment. 

6.5.1  Hardware  Program  Impacts 

There  are  recommendations  contained  in  this  report  that  have  an  impact  on  hardware  system 
program  management.  System  performance  and  compatibility  issues  are  hindering  obtaining 
operational  benefits  that  should  be  realized  from  some  of  the  new  systems.  Some  of  these  issues 
are  long  standing  and  should  be  addressed  before  further  experimentation  with  them  is  carried 
out.  Details  are  contained  throughout  the  report,  particularly  in  Sections  6.8,  6.9,  6.1 1,  and 
Appendices  C  and  E. 


6.6  EXPERIMENT  PLANNING  LESSONS  LEARNED 

Planning  Directive  No  experiment  Planning  Directive  was  published  for  this  FBE-Kilo.  It  is  a 
necessary  document,  supplying  information  that  outlines  responsibilities,  functions,  and  path 
toward  execution  of  an  experiment  event.  Lack  of  this  document  can  cloud  fleet  numbered 
responsibilities  and  makes  “arrangements”  for  support  non-binding  and  unofficial. 

Recommendation :  Use  this  instrument  in  every  FBE  and  LOE  that  is  conducted. 

Forward  FBEs  and  NWDC  Fleet  Presence  Forward  presence  by  the  NWDC  staff  and  key 
planners  was  lacking  for  FBE-Kilo.  Constant  collaboration  with  the  Fleet  is  needed  during 
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experiment  planning.  Unifonned  initiative  leads  were  present  at  the  Fleet  toward  the  end  of  the 
planning  process,  but  many  of  the  other  key  planners  did  not  interact  with  the  Fleet  on  a 
substantial  basis  until  they  arrived  for  execution  of  the  experiment. 

Recommendation :  Insure  key  planners  are  forward  often  in  the  planning  process  and 
hold  the  Final  Planning  Conference  at  the  Fleet's  home  location. 

Fleet  Interface  and  Fleet  Initiative  Sponsors  No  uniformed  Fleet  sponsor  (uniformed 
warfighter)  for  the  Sea  Strike  Initiatives  was  identified  for  FBE-Kilo  for  planning  and  execution. 
Not  having  warfighter  sponsorship  at  the  numbered  fleet  level  for  FBE  initiatives  severely 
hampers  planning  and  coordination. 

Recommendation :  Do  not  examine  initiatives  that  do  not  have  proper  unifonned 
sponsorship  within  the  numbered  Fleet  staff. 

Continuity  Between  Concept  Development  and  Experiment  Implementation  A  lack  of 
continuity  existed  between  the  development  of  FBE-K  concepts/initiatives  involving  ISR/JFN, 
and  the  actual  FBE-K  planning/implementation  for  FBE-Kilo.  This  discontinuity  hampered  the 
development  of  meaningful  analytic  questions,  and  the  experimental  techniques  to  help  answer 
those  questions. 

Recommendation:  Those  involved  in  the  development  of  experimental  concepts  and 
initiatives  remain  fully  engaged  throughout  the  experiment  planning  process  to  ensure  it  is 
properly  focused  on  addressing  original  intent. 


6.7  EXPERIMENT  PREPARATION  LESSONS  LEARNED 

Required  Products  Some  products  required  for  FBE  execution  (AODB,  MIDB,  BSCMs,  etc. . .) 
were  not  available.  The  database  test  was  inadequate,  resulting  in  errant  information  for  use  in 
the  XC4I  systems  used  during  FBE-Kilo. 

Recommendation :  NWDC  must  participate  with  both  planners  and  technologies  in  the 
database  test  process.  If  products  required  are  substandard,  then  they  must  be  identified  and 
corrected  prior  to  execution 

Document  Control  Like  most  previous  FBEs,  Kilo  suffered  from  a  lack  of  document  control 
for  most  of  the  key  coordinating  documents. 

Recommendation :  Early  in  the  FBE  planning  stages,  identify  key  coordinating 
documents  (and  their  owners),  and  implement  an  FBE-wide  common  methodology  for  the 
cooperative  production,  review,  maintenance,  and  accessibility. 

Staff  Participation;  Fleet  Training  vs.  Experimentation  From  the  ISR  perspective,  FBE-Kilo 
degenerated  almost  completely  into  a  JFN  systems  training  event,  largely  because  participation 
by  C7F  Staff  and  Fleet  forces  in  the  planning,  preparation,  and  execution  was  constrained  to 
such  an  extent  as  to  preclude  meaningful  ISR  and  JFN-related  experimentation. 

Recommendation :  Ensure  ISR  and  JFN  related  experimentation  involving  a  numbered 
Fleet  has  full  buy-in  and  participation  of  that  Fleet  staff,  particularly  the  operations  (N3)  staff. 
Focus  experiments  on  experimentation,  not  on  Fleet  training/exercises. 
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Be  prepared  to  postpone  or  cancel  experimentation  events  that  are  dependent  on 
Numbered  Fleet  staff  participation  as  soon  as  it  becomes  obvious  that  the  bulk  of  that 
staffs  focus  will  and  should  be  elsewhere  other  than  on  experimentation. 

Operational  Sequence  Diagrams  Functional  Flow  Diagrams  (FFDs)  should  be  developed  prior 
to  (or  in  conjunction  with)  Operational  Sequence  Diagrams  (OSDs).  They  describe  who  at 
which  functional  nodes  need  (or  will  provide)  what  information  from  (to)  whom  and  why. 

Recommendation :  Institutionalize  FFDs  as  required  documents  for  all  experimentation 
events.  The  OSDs  should  subsequently  (or  concurrently)  be  developed  as  the  technical 
reflection  of  those  FFDs. 

Common  Operational  Picture  (COP)  The  COP  in  FBE-Kilo  did  not  have  explicit  “ownership” 
by  any  initiative,  and  was  not  maintained  to  a  level  required  to  support  ISR  and  JFN  in  support 
of  TST. 

Recommendation'.  Early  in  the  FBE  planning  stages,  identify  who  has  responsibility  for 
each  of  the  many  complex,  interdependent  functions  that  go  into  producing  an  accurate,  stable 
COP  from  which  players  will  be  capable  of  “fighting  the  experiment”.  Consider  doing  the  same 
with  other  “foundational”  FBE  processes,  depending  on  the  nature  of  the  experiment. 


6.8  EXPERIMENT  EXECUTION  LESSONS  LEARNED 

IKA  Support  There  was  no  coordinated  IKA  support  for  FBE-Kilo  execution.  No  IKA  lead 
planning  or  execution  support  was  responsible  for  many  delays  and  training  problems.  Ad-Hoc, 
initiative-level,  IKA  measures  were  implemented  on  the  fly  to  support  execution.  No  clear  level 
of  IKA  support  was  ever  articulated  to  the  planners  during  the  planning  process. 

Recommendation'.  Identify  IKA  (or  other  initiative  area)  participation  level  in  FBE  and 
ensure  that  it  is  maintained. 

Fleet  Execution  Support  Fleet  staff  support  was  inadequate  for  the  Sea  Strike  Initiatives.  The 
promised  JFACC  support  was  also  minimal  and  not  what  had  been  planned.  This  lack  of 
support  was  a  significant  factor  in  not  realizing  the  experimental  potential  of  the  Sea  Strike 
efforts  in  FBE-Kilo. 

Recommendation'.  Insure  the  proper  level  of  Fleet  staff  support  for  an  experiment  will  be 
available  by  frequent  interaction  with  the  uniformed  staff  at  the  ACOS  level. 

Scenario  The  FTX  scenario  did  not  match  (very  closely),  the  FBE  Sea  Strike  live  force 
scenario.  This  was  due  to  the  CJTF  (C7F)  fighting  the  simulation  and  live  scenarios  together 
when  they  were  designed  to  be  separate. 

Recommendation'.  Force  a  higher  level  of  fleet  experiment/exercise  integration 
familiarization  early  and  often  in  the  planning  process. 


6.9  EXPERIMENT  TECHNOLOGY  LESSONS  LEARNED 
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There  is  some  duplication  here  with  material  presented  above  for  Fires  Initiative  conclusions.  It 
is  felt  that  duplication  is  preferable  to  having  the  reader  possibly  miss  important  points  by  not 
examining  both  sections. 

Shipboard  System  Specifications  USS  Blue  Ridge  has  a  10  mb  switch  backbone  that  is 
connected  via  155  mb  links.  This,  along  with  inconsistent  network  card  setting  hindered 
ADOCS  use  during  the  FBE.  Standard,  shipboard  LAN  configurations  that  support  ADOCS 
need  to  be  established.  This  applies  to  switch,  link,  and  network  card  settings  on  these  machines. 
Hardware  limitations  may  require  platforms  to  set  up  multi-server  configurations  to  reduce  the 
effect  of  less  modern  network  backbones. 

Recommendation :  Set  ISNS  ADOCS  standards  prior  to  install  and  configure 
accordingly. 

ADOCS  Recommend  Software  /  Hardware  Changes  Many  recommended  changes  to  ADOCS 
were  compiled  during  the  FBE.  ADOCS  changes  are  indicative  of  command  and  control 
capability  requirements  that  currently  exist. 

Recommendations'. 

Software 

1 .  Ability  to  pair  a  target  to  an  ITO  mission  via  a  button 

2.  Ability  to  highlight  targets  in  Fires  and  JTST  Managers  when  changes  have 
occurred...  alert? 

3.  A  configurable  Fires  Manager  (within  the  ADOCS  GUI). 

4.  Add  “hour  glass”  icon  to  ADOCS  to  display  system  working. 

5.  TST  supported  CDR  indicator  in  JTST  Managers. 

6.  Hot  link  to  ROE  url. 

7.  Hot  link  to  TST  priorities  url. 

8.  Creation  of  a  Combat  Assessment  Manager  and  removal  of  that  function  from  the 
Fires/JTST  managers. 

9.  Hot  link  to  target  folder  url. 

Hardware 

1.  Two  (2)  displays  for  ADOCS  users  that  are  doing  target  development  and 
coordination 

JFN  interaction  with  ADOCS  ATI.ATR  target  nomination  to  JFN  was  incomplete  and  not 
viable  for  usage.  This  problem  needs  to  be  fixed.  It  was  identified  over  2  years  ago  and  is  still  a 
problem. 

Recommendation :  Perform  detailed  ADOCS-JFN  testing  to  fix  this  problem.  This 
should  be  completed  in  the  lab  rather  than  waiting  for  another  experiment. 

Tactical  Exploitation  System  -  Navy  FBE-Kilo  reconfirmed  that  TES-N  has  a  number  of 
powerful  tools  (some  of  which  are  unique  to  TES-N)  that  potentially  could  be  of  great  use  to 
Naval  forces  involved  in  TST.  It  also  reconfirmed  that  TES-N  remains  a  developmentally 
immature  system,  with  extremely  limited  interfaces  to  other  C4I  systems  that  are  critical  to  TST, 
in  particular  GCCS-M  and  ADOCS. 

Recommendation'.  Don’t  use  TES-N  in  any  further  TST-related  experimentation  until 
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major  advances  are  made  to  at  least  the  following: 

•  Interface  with  ADOCS 

•  Interface  with  GCCS-M 

•  Interface  to  PTW  and  any  external  target  folder  applications  (e.g.,  attachment  of  image 
chips  to  ATI.ATR  messages) 

•  Handling  of  ISR  video  and  platform/sensor  telemetry 

•  SCI  COMINT  analysis  tools,  and  SCI-to-GENSER  connectivity  via  ISSE  Guard. 

ELINT  /  ESM  ELINT/ESM  was  sent  from  various  M&S  sources  to  the  TDDS  Network 
Management  Center,  to  be  put  onto  the  TDDS  broadcast,  with  receipt  of  the  broadcast  on  BLR 
via  organic  means,  and  processing  of  exercise/experiment  ELINT  using  the  GALE  software  in 
TES-N. 

•  Successful  receipt  was  achieved 

•  TES-N  GALE  was  unable  to  receive,  process,  and  display  TACELINT  messages  from 
ISR  UUV  that  reported  an  LOB. 

COMINT  COMINT  injects  were  to  be  crafted  by  Kunia  Regional  SIGINT  Operations  Center 
(KRSOC)  scripters  who  were  resident  in  the  TT03  JECG  at  Camp  Smith,  HI.  Injects  would  be 
sent  via  SI  broadcast  to  BLR  and  received  by  a  COMINT  analyst  using  TES-N. 

•  COMINT  injects  were  received  only  on  SCI  GCCS-M,  as  that  is  the  way  the  BLR  SCI 
architecture  was  configured. 

•  The  COMINT  analyst  at  the  SCI  GCCS-M  received  the  injects  as  emails,  printed  them, 
and  sneaker-netted  them  to  the  TST  team  manning  TES-N  terminals. 

•  TES-N  does  not  have  any  true  COMINT  analysis  tools  (as  does  SCI  GCCS-M). 

•  TES-N  Information  Support  Server  Environment  Guard  was  non-functional  on  BLR. 


Target  nomination  messages  (ATI.ATRs)  to  ADOCS  and  to  TST  Target  Folder  Server  The 
objective  was  for  the  TST  nomination  analyst  to  use  TES-N  to  create  a  target  nomination 
message  (in  USMTF  “ATI.ATR”  format),  and  to  send  that  nomination  message  (via  SMTP)  to 
the  ADOCS  server  on  BLR,  and  to  the  TST  Target  Folder  server  at  NWDC.  Considerable  effort 
was  required  to  get  all  systems  interoperating  correctly,  TES-N  LAN,  ship’s  LAN/Exchange 
server,  FBE-K  WAN  and  Exchange  servers,  ADOCS  mail  server.  Once  set  up  properly  the 
process  worked  well. 

Target  identification  difficulties  Inconsistencies  existed  in  how  target  nominations  were 
handled  by  ADOCS  and  how  they  were  showing  up  in  the  TST  Target  Folder  server.  The  fault 
was  in  both  TES-N  and  ADOCS,  with  inconsistencies  in  target  line  usage.  ADOCS  turned 
around  an  ATI.ATR  with  fields  out  of  order  and  truncated. 

Images  related  to  target  nominations  to  PTW  for  aim-point  refinement  The  objective  was  to 
attach  images  (e.g.,  video  “chips”  showing  the  TST)  to  the  outgoing  target  nomination,  and  send 
the  nomination  simultaneously  to  ADOCS,  TST  Target  Folder,  PTW. 

•  The  version  of  PTW  used  on  BLR  could  not  receive  and  parse  ATI.ATR  messages  (i.e., 
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did  not  have  the  DTMS  software  used  in  MC02/FBE-J). 

•  TES-N  does  not  allow  images  to  be  attached  to  outgoing  ATI.ATRs. 

•  All  images  captured,  chipped,  and  saved  (as  NITF)  in  TES-N  had  to  be  manually 
transferred  (FTP)  to  PTW. 

•  The  PTW  operator  would  pull  up  the  images  and  conduct  aimpoint  refinement,  then  save 
the  images  (as  both  JPEG  and  NITF)  to  a  shared  directory  on  the  BLR  IT-21  LAN. 

Images  related  to  target  nominations  to  TST  Target  Folder  Server  The  objective  was  for  the  TST 
nomination  analyst  to  attach  images  to  the  outgoing  target  nomination  so  that  the  TST  Target 
Folder  server  could  add  the  image(s)  to  the  TST’s  target  folder. 

•  TST  Target  Folder  server  worked  well  and  the  NWDC  TST  Target  Folder  server 
application  proved  to  be  a  simple  but  powerful  prototype. 

•  The  new  version  5.0  of  TES-N  software  still  cannot  attach  images  to  ATI.ATRs. 

File  transfer  to  ISRM  (CPX)  and  ESSEX  RTC  /  RTC  Lites  (FTX)  Because  “DIOP”  is  only  for 
the  transfer  of  U-2  imagery  that  is  being  (or  has  just  been)  directly  downlinked,  other  file  types 
must  be  exchanged  between  TES-N  and  remotes  like  ISRM  and  RTCs  using  standard  means 
such  as  FTP  and  SMTP. 

•  FTP  and  SMTP  worked  well. 

•  RTC  Lites  worked,  with  varying  difficulty.  RTC  Lite  at  NUWC  was  fairly  easy  to  get 
up,  configuring  the  others  was  difficult. 

Cross-INT  replication  from  TES-N  to  ISRM  (CPX)  and  ESSEX  RTC  (FTX)  Replication  of 
TES-N’s  Cross-INT  database  was  attempted  to  both  ISRM  (CPX)  and  the  ESX  RTC  (FTX),  but 
with  very  limited  success. 

•  During  CPX,  Cross-INT  was  not  replicated  to  ISRM  due  to  ISRM  instability  problems. 

•  During  FTX,  Cross-INT  was  replicated  to  ESX  RTC. 

•  Target  Nominations  created  in  TES-N  are  not  replicated  to  ISRM  /  RTC. 

6.10  EXPERIMENT  COP  ISSUES 

M&S  simulated  ISR  asset  display  in  GCCS-M  COP  By  the  end  of  FTX,  all  of  the  simulated 
Blue  ISR  assets  active  in  M&S  were  simultaneously  displayed  on  BLR’s  GCCS-M  COP  with 
appropriate  labels  (e.g.,  two  ISR  UUVs,  two  Predator  UAVs,  one  U-2).  This  was  the  first  time 
that  this  has  happened  in  an  FBE. 

TST  location  output  to  COP  (i.e.,  Manual  Contact  to  GCCS-M)  for  “tracking”  and  SA):  The 
objective  was  for  the  TST  nomination  analyst  to  not  only  create  an  ATI.ATR  as  above,  but  to 
then  use  TES-N’s  rudimentary  interface  to  GCCS-M  to  input  the  target  into  the  COP  as  a  track, 
for  the  situational  awareness  of  ALCON,  and  to  assist  (theoretically)  in  the  “tracking”  of  the 
TST  while  waiting  for  it  to  be  engaged. 

•  The  TES-N  output  to  GCCS-M  only  worked  for  two  days  at  the  same  rudimentary  and 
suboptimal  level  at  which  it  was  working  for  MC02/FBE-J;  for  the  remainder  of 
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TT03/FBE-K  it  was  functionally  inoperative. 

•  Even  with  the  new  TES-N  version  5.0,  there  was  no  improvement  in  TES-N’s  ability  to 
output  to  GCCS-M  from  what  was  used  in  MC02/FBE-J. 

GCCS-M  COP  Tracks  into  TES-N  ITD  In  addition  to  TES-N’s  rudimentary  capability  to  send 
“Manual  Contacts”  to  GCCS-M,  COP  tracks  can  also  be  sent  from  GCCS-M  to  TES-N.  The 
objective  of  attempting  to  do  so  was  to  provide  a  richer  context  of  contacts,  tracks,  Blue  ISR 
asset  locations,  etc.,  in  TES-N  for  the  analysts  trying  to  find  and  fix  TSTs. 

•  TES-N’s  incoming  “Message  and  Data  Log”  showed  a  good  number  of  incoming  tracks 
from  GCCS-M,  but  those  tracks  did  not  appear  to  be  parsing  into  the  TES-N  ITD. 

•  When  GCCS-M  tracks  coming  into  TES-N  were  able  to  be  brought  up  on  the  ITD  it  did 
not  display  any  track  labels. 

o  GCCS-M  tracks  in  TES-N’s  ITD  appeared  in  their  proper  locations  but  the 
symbols  do  not  have  any  labels  associated  with  them  (e.g.,  no  track  names), 
making  them  all  but  functionally  useless  to  the  TST  team. 

6.11  ORGANIZATION  CONCLUSIONS 

Time  Critical  Targeting  Functionality  Afloat  The  Xray  Papa  cell  was  an  excellent  test  case  for 
familiarization  of  the  TCTF  concept  to  the  fleet.  TCTF  is  a  USAF  program  that  outlines  the  C2 
requirements  and  systems  for  conducting  TCT  operations.  In  support  of  JCC  and  JCC  (Afloat), 
the  USN  needs  to  further  refine  this  concept  to  support  both  joint  and  maritime  forces  from  a  flag 
configured  platform. 

Recommendation :  Use  TCTF  Afloat  a  starting  point  for  future  Sea  Strike  initiatives. 

Xray  Papa  and  Maritime  Component  Time  Sensitive  Targeting  The  Xray  Papa  cell  identified  a 
time  sensitive  targeting  gap  at  the  maritime  component  level  that  needs  to  be  addressed. 
JFMCC’s  conduct  of  broad  scale  TST  operations  that  are  integrated  with  other  components  is 
beyond  the  traditional  role  of  the  Bravo  Papa.  A  staff  function  at  the  operational  level  (JFMCC) 
that  supports  TST  prosecution  is  required. 

Recommendation :  Integrate  this  effort  with  the  TCTF  effort  described  above  to  help 
identify  maritime  TST  command  and  control  requirements  of  the  future. 


6.12  FBE  DATA  LESSONS  LEARNED 

There  have  always  been  problems  in  FBEs  with  obtaining  all  of  the  data  needed  from  the  various 
hardware  systems  to  form  complete  Fires  timelines.  This  was  not  improved  for  FBE-Kilo. 

Referring  to  Table  4.1,  we  see  that  only  9  of  the  required  24  data  elements  were  obtained.  We 
repeat  the  data  overview  statement  from  Section  5.3.1: 

Compared  to  other  recent  FBEs  the  objective  data  provided  for  this  experiment  was  deficient 
in  quantity  and  quality.  In  particular: 

•  The  provided  TES-N  covered  only  a  few  days  of  the  CPX  and  was  reformatted  so  as  to 
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be  unusable. 

•  No  GISRC  data  were  provided. 

•  The  ADOCS  JTST  manager  did  not  set  capture  mission  histories  for  the  last  two  days  of 
the  experiment 

•  After  acquiring  excellent  mensuration  data  from  RRF  in  FBE-J,  FBE-K  reverted  to  PTW 
which  has  never  provided  usable  data. 

•  The  JSAF  event  data  logged  in  SNN  did  not  include  Fire  events.  There  were  gaps  in  the 
JSAF  event  data  and/or  many  fire  commands  did  not  reach  JSAF. 

There  continues  to  be  a  problem  with  Fires  systems  not  being  time  synchronized. 

Ironically,  even  though  the  data  situation  was  worse  in  Kilo,  the  impact  was  not  as  large  as  it  has 
been  for  other  experiments.  This  is  because  former  experiment  results  depended  strongly  on 
being  able  to  develop  valid,  quantitative,  TST  timelines.  Here  we  have  been  interested  in 
broader  issues  such  as  CONOPS  and  how  JFN  contributes  to  TST  processes.  Even  so, 
degradation  in  the  ability  to  obtain  needed  electronic  data  does  not  bode  well  for  future 
experimentation. 

Recommendation :  Develop  a  program  to  insure  needed  electronic  data  is  made  available 
from  all  systems  that  are  part  of  the  TST  process,  including  simulations. 

The  following  are  implementation  measures  for  the  recommended  program.  In  future 
experimentation  the  application  of  these  measures  would  do  much  to  improve  the  collection  of 
objective  data: 

a.  Require  for  system  participation  in  an  experiment  that  the  system  incorporate 
tools  that  would  log,  identify  and  timestamp  all  significant  operator  actions. 

b.  Require  data  logging  in  formats  that  can  be  easily  manipulated  for  post 
experiment  analysis. 

c.  Include  as  an  objective  in  pre-experiment  integration  testing  the  validation  of  the 
data  logging  applications. 
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Appendix  A  ADOCS  TST  PROCEDURES  CHAT 


This  Appendix  contains  an  extensive  discussion  collected  from  the  AIROPS  IRC  channel  on 
April  30  that  illustrates  the  participant  confusion  regarding  ADOCS  TST  procedures  that 
persisted  even  in  the  closing  days  of  the  experiment. 

The  nomination  discussed,  GEO  157,  was  a  tracked  vehicle  target  nominated  by  the  E-2C  GISRC 
and  was  received  in  ADOCS  at  300137Z  The  target  was  paired  to  TACAIR  mission  1023.  The 
target  was  not  engaged. 

[02:58]  <XP_E2X>  MSN  GE0157 
[02:59]  <E2C-5>  MSN  0157 
[03:00]  <XP_E2X>  take  a  look  at  it  in  ADOCS 
[03:00]  <E2C-5>  looking  at  it 

[03:01]  <E2C-5>  we  nominated  it  about  an  hour  and  a  half  ago 
[03:01]  <XP_E2X>  acknowledge 

[03:01]  <E2C-5>  is  there  something  you  want  to  know  about  it? 

[03:01]  <XP_E2X>  understand  the  process  takes  a  while 
[03:01]  <E2C-5>  what  process/ 

[03:01]  <E2C-5>? 

[03:02]  <XP_E2X>  ADOCS  TST  process 
[03:03]  <E2C-5>  ADOCS  is  almost  immediate 
[03:03]  <XP_E2X>  have  you  acknowledged  in  ADOCS 
[03:03]  <E2C-5>  acknowledged  what?  we  nominated  it 

[03:04]  <XP_E2X>  yes  but  it  has  to  be  assigned/WTP  etc  you  don't  own  it  until  XP  tells  you  do 
[03:04]  <E2C-5>  ok,  so....  ARE  you  TELLING  me  to  WTP  it? 

[03:04]  <E2C-5>  I  can  DO  that 

[03:05]  <XP_E2X>  it  already  has  been  but  if  you  have  a  closer  or  better  asset  then  make  the 
recommendation  to  XP 

[03:07]  <E2C-5>  I  don’t  know  what  we’re  waiting  for.  The  tactical  picture  changes  in  the  period 
of  an  hour  and  a  half.  WTP  is  only  good  for  so  long. 

[03:07]  <E2C-5>  I  can  change  the  WTP  when  you  want  to  fire.  If  I  WTP  and  then  an  hour  and  a 
half  goes  past,  then  I  might  not  even  have  the  same  assets  in  the  air. 

[03:09]  <E2C-5>  If  you  don’t  want  to  kill  the  target,  there’s  literally  no  point  in  doing  WTP. 
[03:11]  <E2C-5>  Standing  by  for  tasking... 

[03:16]  <E2C-5>  where  are  we  in  the  process  at  this  point.  Is  there  anything  we  can  do  to  help 
the  process  along? 

[03:22]  <XP_E2X>  if  we  don’t  assign  it  as  TST  we  wait  to  make  a  decision  if  we  want  to  attack 
or  not  or  wait  until  tomorrow's  ATO 

[03:23]  <XP_E2X>  in  the  mean  time  you  can  change  your  box  for  msn  GEO  157  blue=ack 

[03:24]  <XP_E2X>  YYYYEEEESSSS 

[03:24]  <E2C-5>  ok,  what  does  acknowledge  mean? 

[03:24]  <E2C-5>  what  am  I  acknowledging? 

[03:25]  <XP_E2X>  that  you  understand  that  the  msn  is  being  assigned  to  you  and  assets  under 
your  control  if  we  should  decide  to  attack  it 
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[03:25]  <E2C-5>  do  we  have  to  WTP  in  order  to  desig  as  a  TST?  I  would  think  that  TST 
decision  would  be  independent  of  the  weapon  used  to  execute. 

[03:26]  <XP_E2X>  after  we  both  go  blue=ack  then  ADC  will  go  red  until  the  TST  or 
deconfliction  is  complete 

[03:26]  <E2C-5>  how  do  I  know  that  I  should  go  blue? 

[03:26]  <XP_E2X>  do  you  have  JMEMS  airborne 
[03:27]  <E2C-5>  no 

[03:27]  <XP_E2X>  blue=ack  do  you  have  the  color  box  matrix  we  forwarded 
[03:27]  <E2C-5>  we  have  the  matrix 
[03:28]  <XP_E2X>  then  read  along 

[03:29]  <E2C-5>  when  we  are  assigned  a  mission,  we  assume  that  the  decision  to  execute  has 
been  made. 

[03:29]  <XP_E2X>  not  until  the  boxes  are  turned  the  correct  colors 
[03:29]  <XP_E2X>  by  ALL  PLAYERS  involved  in  the  process 

[03:30]  <E2C-5>  ok,  so  you  need  to  tell  me  that  I  should  expect  to  be  tasked  with  a  mission,  then 
that  I  will  be  tasked  with  a  mission,  then  that  I  should  execute  the  mission.  Is  that  correct? 

[03:30]  <XP_E2X>  it  hasn’t  been  nom’ed  as  a  TST  so  XP  is  making  a  determination  if  they  care 

to  attack  it  or  not 

[03:30]  <XP_E2X>  correct 

[03:31]  <XP_E2X>  unless  tasked  directly  from  the  JLACC 

[03:3 1]  <E2C-5>  ok,  would  it  be  possible  for  you  to  just  tell  me  when  you  want  to  execute  a 
target? 

[03:32]  <E2C-5>  or  are  we  strapped  to  these  rules? 

[03:33]  <XP_E2X>  check  the  box  in  ADOCS  I  will  turn  XPA  green=ready  to  engage  then  you 
turn  your  box  green 

[03:33]  <XP_E2X>  I  will  also  pimp  you  via  chat 
[03:33]  <E2C-5>  ok 

[03:34]  <XP_E2X>  this  is  the  process  using  ADOCS. ..and  that  is  what  we  are  sitting  out  here 
trying  to  do 

[03:34]  <XP_E2X>  what  did  you  think  we  were  doing 

[03:35]  <XP_E2X>  wow  it  only  took  a  week  to  achieve  this  level  of  understanding 
[03:35]  <E2C-5>  I  guess  with  this  process  I  can  understand  why  it  takes  so  long. 

[03:37]  <E2C-5>  again,  I  refer  you  to  the  fact  that  by  the  time  all  this  happens,  we  might  have 
lost  the  assets  we  were  planning  on  executing  with,  and  cause  us  to  go  back  to  the  beginning 
with  the  new  WTP. 

[03:37]  <E2C-5>  Cycle  time  on  a  Hornet  is  not  in  excess  of  1.5  hours,  he  very  well  might  be  on 
tanker  when  the  decision  comes  through 

[03:39]  <E2C-5>  The  optimal  air  asset  to  execute  a  target  changes  in  a  period  of  15  minutes. 
We’ll  play  by  the  experimental  rules,  but  want  to  make  sure  all  are  aware  of  the  issues  involved 
in  this  process  to  real  world  ops. 

[03:39]  <E2C-5>  so  now  I'm  waiting  for  your  box  to  go  green  right? 

[03:42]  <XP_E2X>  understand.. that's  why  if  the  asset  need  to  be  updated  you  need  to  pass  that 
along  to  XP  and  go  into  ADOCS  saying  you  can't  execute.. go  to  chat  explain  the  what  the  plan  is 
will  be  hammered  out. 

[03:42]  <E2C-5>  also  be  advised  if  you're  looking  to  execute  on  this  target,  we’re  going  to  need 
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to  update  the  WTP  for  this  target,  the  original  asset  has  RTB’d 
[03:43]  <E2C-5>  we  can  still  execute,  just  with  a  different  asset 
[03:43]  <XP_E2X>  don’t  think  TST  as  within  the  next  5  mins. ..for  now 
[03:44]  <XP_E2X>  noted  on  asset  update 

[03:47]  <XP_E2X>  be  advised  the  people  in  the  JIC/JFACC/JCMCC/XP/BLR/&  the  Fleet  have 
never  seen  or  ever  worked  with  these  systems  before. .and  identifying  this  process  is  what  we  are 
here  for... remember  who  the  customer  is  is  not  the  guys  in  Newport  with  there  joystick  in  there 
hands  but  7th  fleet 

[03:48]  <E2C-5>  I  recognize  that.  I'm  trying  to  help  you  guys.  I'm  just  trying  to  point  out  where 

the  system  is  going  to  break  in  the  real  world 

[03:48]  <E2C-5>  right  now  I  can’t  pair  anything  in  LAWS 

[03:49]  <E2C-5>  I've  already  changed  the  time  to  allow  for  targeting,  as  it  had  turned  red 
[03 :49]  <E2C-5>  the  NLT  I  mean 

[03:49]  <E2C-5>  now  LAWS  is  saying  that  all  my  assets  will  have  no  effect  on  the  target. 
[03:49]  <E2C-5>  we’re  going  to  re-start  ADOCS 
[03:49]  <E2C-5>  standby 

[03:5 1]  <XP_E2X>  I  knew  that  when  we  started  but  again  this  is  there  first  introduction  to 
ADOCS...  no  Subject  matter  experts  just  a  bunch  of  guys  trying  to  figure  out  what  these  box  do 
[03:52]  <XP_E2X>  I  changed  your  box  white  until  we  develop  things  better  here 
[03:52]  <E2C-5>  just  don't  want  it  figured  out  in  a  way  that  won't  work 
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Appendix  B  SPECIFIC  TARGET  TIMELINE  AND  INFORMATION 


This  Appendix  contains  information  for  five  targets.  There  are  Annexes,  each  containing  a 
timeline  for  a  selected  TST  engagement.  Following  the  timestamp  for  each  entry  in  the  timeline 
is  the  source  of  the  infonnation.  This  will  be  a  system  (e.g.  ADOCS)  or  an  IRC  chat  channel.  In 
the  case  of  the  ADOCS  Mission  History,  the  agent  for  the  change  is  identified.  For  IRC,  the 
specific  chat  channel  is  cited  followed  by  the  name  of  the  node  initiating  the  communication.  If 
the  channel  was  in  the  Coalition’s  IRC  net  the  name  of  the  channel  is  followed  by  “(Coalition 
channel)”. 


All  times  are  GMT. 


Annex 

Target  # 

Engagement 

B1 

TB0050 

TES-N  nominated  SA-15  engaged  by  DDX  LRLAP 

B2 

TB0051 

TES-N  nominated  SCUD,  WTP  to  TACAIR  but  not  engaged 

B3 

AB5027 

BLR  nominated  vehicle,  convoy  engaged  by  ANZAC  with 

ERGM 

B4 

GX0321 

DDX  nominated  field  artillery  engaged  by  ANZAC  with  ALAM 

B5 

AA0368 

ANZAC  nominated  cruise  missile  site  engaged  by  DDX  with 
TLAM 

Annex  B1  -  Nomination  TB0050 
l.Timelime 

TB0050  was  an  April  30  nomination  of  an  SA-15  target  by  TES-N.  The  target  was  prosecuted  by 
the  DD-X  with  8  LRLAP  rounds.  Table  Bl.l  shows  the  critical  timeline  events.  All  actions  and 
IRC  communications  related  to  the  TB0050  engagement  are  listed  in  Section  4. 
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Table  Bl.l  TB0050  Timeline 


Event 

Time 

Nomination  received  in  ADOCS 

00:13 

XP  acknowledges  mission 

00:23 

Begin  strike  planning  (TCT  =yellow) 

Not  done 

Target  confirmed  TST 

Not  done 

Nomination  promoted  to  JTST 

00:23 

JOCC  WTP  to  DDX 

00:29 

ADC  initiates  deconfliction 

00:34 

DDX  assigned  mission 

00:34 

DDX  acknowledges  mission  assignment 

00:37 

NLT  time 

02:13 

Target  is  deconflicted 

03:28 

XP  authorizes  engagement 

03:28 

DDX  accepts  mission 

03:28 

DDX  fire  when  ready 

03:43 

LRLAP  Fired 

03:57 

The  interval  between  the  receipt  of  the  mission  and  the  fire  event  was  three  hours  and  44 
minutes.  This  mission  is  considered  a  failure  since  it  was  not  fired  until  200  minutes  after  the 
NLT  time.  This  failure  was  due  to  a  large  unexplained  interval  between  the  DDX 
acknowledging  the  mission  (00:37)  and  the  appearance  in  ADOCS  of  various  mission  approvals 
(03:28) 

LRLAP  is  a  precision  weapon  that  normally  would  require  a  precise  target  position.  Target 
mensuration  was  not  discussed  regarding  this  mission  and  a  mensurated  position  does  not  appear 
in  the  ADOCS  tabs.  The  salvo  of  eight  rounds  may  have  been  considered  to  override  the 
requirement  for  a  precise  target  position. 

2.TTP 

The  ADOCS  actions  in  this  engagement  are  compared  to  the  ADOCS  TST  TTP  outlined  in 
Table  7  and  Table  8. 

The  ADOCS  TTP  (Table  8)  indicates  that  the  TCT  block  should  be  used  (turned  yellow)  to 
initiate  strike  planning  for  a  TST.  It  was  not  so  used  in  this  engagement.  The  JIC  turned  the  TCT 
block  blue  (at  00:3 1).  This  an  undefined  color  choice  in  the  ADOCS  TTP  and  hence 
meaningless. 

The  BLR  turned  the  DDX  block  to  back  to  yellow  (01 :05)  after  the  shooter  had  changed  it  to 
blue.  This  action  is  undefined  and  unexplained. 

The  JIC  Air  IPB  set  the  ADC  block  to  red  (00:54)  but  the  BLR  SPARE  4  set  it  to  green  (03:15) 
indicating  deconfliction  was  completed.  The  latter  workstation  also  simultaneously  set  the  DDX 
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(this  is  a  DDX  responsibility)  and  XPA  blocks  to  green.  This  appears  as  an  unrealistic  action 
performed  after  more  than  an  hour  of  no  action  in  order  to  force  the  engagement  to  a  conclusion. 

At  3:52  the  DDX  requests  permission  to  engage.  XP  says  the  display  is  all  green  and  instructs 
him  to  fire.  If  the  DDX  display  was  all  green  he  should  not  have  wasted  time  in  seeking 
pennission  to  fire.  If  his  display  was  not  all  green  due  to  ADOCS  latencies  then  he  had  to  resort 
to  chat  to  get  fire  permission.  In  either  case,  the  potential  for  ADOCS  as  a  tool  to  expedite  the 
TST  engagement  process  is  not  being  realized. 

3.ADOCS 

ADOCS  is  the  primary  tool  and  data  source  in  the  engagement  of  TSTs.  Failures  or 
inconsistencies  in  ADOCS  have  an  important  impact  on  the  engagement  process  and  experiment 
analysis.  Some  of  the  problems  encountered  in  this  mission  are  listed  below 

The  time  the  nomination  was  received  in  ADOCS  as  indicated  in  the  mission  history  (00: 13)  and 
in  the  fire  mission  targeting  tab  (00:59)  are  inconsistent.  The  latter  time  is  incompatible  with 
the  IRC  data  therefore  the  former  time  is  adopted. 

The  JTST  Mission  History  was  very  incomplete.  Only  a  single  event  was  recorded 

There  appears  to  be  a  time  problem  between  the  IRC  times  and  the  ADOCS  times.  For 
example,  in  IRC  it  is  reported  the  mission  was  fired  at  3:57,  but  the  FRD  block  turned  green  in 
ADOCS  at  3:45.  It  is  known  that  the  IRC  chat  times  were  accurate  to  within  two  or  three 
minutes. 

There  are  sometimes  substantial  latencies  in  the  receipt  of  color  block  changes  by  all 
workstations.  Some  examples: 

a.  at  3:27  XPDDX  states  the  TB0050  mission  is  all  green.  At  3:30  TAODDX  reports  that 
on  his  display  XPA  is  yellow  and  ADC  is  red. 

b.  At  0:50  DDX  turns  the  DDX  blue  to  acknowledge  the  mission,  at  1 :05  BLR  turns  the 
block  yellow,  at  1 :24  DDX  turns  it  back  to  blue.  At  1:50  XP  DDX  requests  DDX 
acknowledge  the  mission.  At  1:54  XP  DDX  tells  DDX  the  box  should  go  blue.  At  1:58 
TAO  DDX  responds  that  his  DDX  box  is  blue.  Apparently  XP  DDX  does  not  hold  on 
his  ADOCS  display  the  acknowledgment  (blue  DDX  block)  made  by  DDX  30  minutes 
ago 

c.  This  problem  is  also  illustrated  by  Table  B 1 .2  Which  shows  the  final  state  of  the 
ADOCS  Fires  display  from:  the  Mission  Coordination:  Fires  Mission  History,  the  BLR 
Mission  Coordination:  Fires  display  and  the  Newport  Mission  Coordination:  Fires 
display.  The  BLR  display  shows  the  WRD  and  FRD  blocks  white  rather  than  green. 
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Table  B1.2.  Final  Mission  state  from  Different  ADOCS  sources 


Source 

TCT 

XPA 

E2X 

DDX 

ANZ 

ADC 

WRD 

FRD 

BDA 

Mission  History 

G 

G 

G 

G 

G 

Mission  Coordination: 
Fires  display  BLR 

G 

G 

G 

Mission  Coordination: 
Fires  display  Newport 

G 

G 

G 

G 

G 

The  Fires  Mission  History  exhibits  a  number  of  inconsistent  coordination  block  changes  that 
may  be  attributable  to  ADOCS  latency.  An  example: 

At  2:03  the  DDX  server  ADOCS  workstation  turns  the  DDX  block  from  blue  to  green.  At  2:05 
the  DDX  Shooter  1  ADOCS  workstation  turns  the  DDX  block  from  blue  to  green.  The  block 
should  have  already  green.  At  3:28  BLR  turns  the  DDX  block  from  yellow  to  green,  but  the 
block  was  already  green  and  was  last  yellow  at  1 :24.  An  interpretation  of  these,  and  other  similar 
anomalies,  is  that  the  earlier  changes  to  the  DDX  had  not  arrived  at  the  workstation  making  the 
change  and  so  it  made  the  change  based  on  the  color  of  the  block  it  displayed. 

In  the  JTST  display  the  MSN  block  status  is  yellow  EXE  indicating  the  mission  was  not  fired. 

4.TimeIine  actions  and  events. 

Listed  below  in  time  tagged  order  are  all  significant  IRC  channel  communications  and  ADOCS 
actions  obtained  from  the  ADOCS  Mission  History  logs  that  relate  to  TB0050. 

00:13  ADOCS  Fires  Mission  History.  Time  the  nomination  was  received  in  ADOCS  from  TES- 
N. 

00:20  ADOCS  Fires  Mission  History.  JIC  RFI  ASST  refines  target  type  as  SA-15  and  modifies 
the  target  Not  Later  Than  (NLT)  Time. 

00:23  ADOCS  Fires  Mission  History  /  JTST  target  data  tab.  The  nomination  is  promoted  to 
JTST. 

00:23.  ADOCS  Fires  Mission  History.  JOCC  turns  XPA  block  yellow  indicating  XP 
acknowledges  the  mission. 

[00:28]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP.  received  TCT  for  TB0050,  hold  DDX 
Coord  box  as  white. 

00:29.  ADOCS  Fires  Mission  History.  JOCC  WTP  the  target  to  DDX  and  LRLAP. 

00:31.  ADOCS  Fires  Mission  History.  JIC  Air  IPB  turns  TCT  block  blue. 

00:37  ADOCS  Fires  Mission  History.  DDX  sets  mission  volley  size  to  8. 

00:47  ADOCS  Fires  Mission  History.  JIC  Air  IPB  turns  ADC  block  red  indicating  the  mission 
is  being  deconflicted. 

00:47  ADOCS  Fires  Mission  History.  JIC  Air  IPB  turns  DDX  block  to  yellow.  Indicating  the 
mission  is  assigned  to  DDX. 
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00:50  ADOCS  Fires  Mission  History.  DDX  turns  the  DDX  block  yellow  to  blue  indicating  he 
acknowledges  the  mission  assigned  to  him. 

01 :05  ADOCS  Fires  Mission  History.  BLR  turns  DDX  block  from  white  to  yellow. 

01 :24  ADOCS  Fires  Mission  History.  DDX  turns  the  DDX  block  from  yellow  back  to  blue. 

[01:38]  IRC.  MARITIMEOPS.  <TAO_vDDX>  XP...  req  WTP  TB0050  for  LRLAP  mission. 

[01:45]  IRC.  MARITIME  OPS.  <XP_DDX>  DDX  RGR  wait  one 

[01:50]  IRC.  MARITIME  OPS.  <XP_DDX>  DDx  TAO  pis  ack  receipt  of  tgt  TB0050  on 

ADOCS 

[01:54]  IRC.  MARITIME  OPS.  <TAO_vDDX>  DDX  shows  ADC  holding  TB0050  red. 

[01:54]  IRC.  MARITIME  OPS.  <XP_DDX>  rgr  DDx  box  should  go  blue 

[01:56]  IRC.  MARITIME  OPS.  <TAO_vDDX>  rgr  blue 

[01:58]  IRC.  MARITIME  OPS.  <TAO_vDDX>  DDX  shows  our  box  blue 

02:03  -  02:16  ADOCS  Fires  Mission  History.  DDX  made  multiple  changes  to  the  DDX  block 

with  the  block  starting  and  ending  blue. 

02:13.  ADOCS.  NLT  time 

[03:27]  IRC.  MARITIME  OPS.  <XP_DDX>  DDx-TAO  TB0050  is  all"green"  engage  tgt. 
Please  confirm  though  what  you  show 

03:28  ADOCS  Fires  Mission  History.  BLR  (spare  4)  turns  ADC  block  green  indicating  the 
mission  is  deconflicted 

03:28.  ADOCS  Fires  Mission  History.  BLR  (spare  4)  turns  XPA  block  green  meaning  the 
shooter  is  cleared  to  engage. 

03:28.  ADOCS  Fires  Mission  History.  BLR  (spare  4)  turns  DDX  block 

[03:30]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP...  We  show  XPA  as  yellow;  DDX  as  green; 

ADC  still  red. 

[03:30]  IRC.  MARITIME  OPS.  <XP_DDX>  TAO  DDx  confirm  u  r  in  positive  control  of 
UAV2 

[03:31]  IRC.  MARITIME  OPS.  <XP_DDX>  rgr  ddx. 

[03:31]  IRC.  MARITIME  OPS.  <TAO_vDDX>  DDX  has  pos  control  of  UAV2 
[03:31]  IRC.  MARITIME  OPS.  <XP_DDX>  u  r  authorized  to  engaged  vis  this  chat. 

[03:38]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP...  having  probs  with  NFCS.  Req  WTP 
TB0050  with  TLAM. 

03:43  ADOCS  Fires  Mission  History.  DDX  turns  fire  when  ready  block  green. 

[03:50]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP...  DDX  can  now  execute  TB0050  with 
LRLAP. 

[03:52]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP...  NFCS  is  down  but  ADOCs  is  up.  We’ll 
use  ADOCs  for  LRLAP  msns. 

[03:52]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP..  Req  permission  to  engage  TB0050  with 
LRLAPs. 

[03:53]  IRC.  MARITIME  OPS.  <XP_DDX>  I  show  all  green  for  pennission.  Engage  TB0050 
[03:55]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP...  DDX  engaging  TB0050  with  8  LRLAP 
mds. 

[03:56]  IRC.  MARITIME  OPS.  <TAO_vDDX>  XP..  LRLAP  mds  away  at  0357 
03:58  ADOCS  Fires  Mission  History.  DDX  turns  FRD  block  green.  Mission  fired. 

Annex  B2  -  Nomination  TB0051 
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1.  Timeline  TB0051 


This  was  an  April  30  TES-N  nomination  of  a  SCUD  target.  The  mission  was  assigned  to 
TACAIR  but  not  executed.  Table  Bl.l  shows  the  critical  timeline  events.  All  actions  and  IRC 
communications  related  to  the  TB0051  engagement  are  listed  in  Section  4. 

Table  B2.1  TB0051  Timeline 


Event 

Time 

Nomination  received  in  ADOCS 

00:41 

JIC  refines  target  type  and  NLT 

00:43 

Nomination  promoted  to  JTST 

00:44 

XP  acknowledges  mission 

00:44 

Deconfliction  initiated 

Not  done 

Deconfliction  complete 

01:16 

WTP  ATO  mission  Homet21 

01:22 

Mission  assigned  to  E2-C 

01:27 

target  type  refined 

01:38 

WTP  ATO  mission  LOITER07 

01:56 

NLT  time 

02:41 

WTP  ATO  mission  HORNET65 

03:43 

E-2C  ack  assignment 

Not  done 

E-2C  accepts  mission 

Not  done 

XP  ack  mission  acceptance 

Not  done 

XP  authorizes  mission 

Not  done 

At  various  times,  the  target  was  assigned  to  three  different  ATO  missions  and  at  different  times  a 
U-2  and  a  Predator  were  on  station  to  obtain  BDA.  But  it  appears  from  ADOCS  and  IRC  that 
the  target  was  ever  engaged.  From  IRC,  it  is  clear  that  the  E2C  did  not  see  the  mission  in  his 
ADOCS.  It  did  appear  in  the  ADOCS  viewed  by  the  TSTLNO.  Since  the  E2  does  not  hold  and 
could  not  act  on  the  mission,  TST  LNO  arbitrarily  assigned  a  TOT  time. 

E-2C  never  acknowledged  assignment  of  the  mission  to  him  because  the  mission  did  not  appear 
in  his  ADOCS.  XP  never  went  green  to  authorize  mission  engagement. 

The  original  experiment  plan  was  to  enter  georefinement  results  into  the  ETF.  It  was  requested 
for  this  mission  ( 1 :09)  that  georefinement  results  be  entered  in  the  JTST  Target  Data  tab.  There 
is  no  indication  there  or  elsewhere  that  target  georefinement  was  ever  performed. 

The  IRC  contains  several  example  of  particular  nodes  having  to  type  the  same  message  in 
multiple  chat  channels.  This  inefficiency  should  be  mitigated  by  a  more  careful  assigning  of 
functions  and  participants  to  particular  channels. 

2  TTp 

At  1:16  the  JAOC  SIDO  turned  the  ADC  block  from  white  to  green  indicating  deconfliction  was 
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complete.  The  block  was  never  turned  red  as  required  to  indicate  deconfliction  was  underway. 
Further,  the  deconfliction  was  complete  before  the  mission  was  formally  WTP  to  Hornet2 1 
although  that  pairing  was  discussed  in  IRC  before  it  was  implemented.  However,  the  target  was 
subsequently  WTP  to  two  other  ATO  missions.  Presumably  the  deconfliction  result  would  not 
apply  to  these  subsequent  missions 

At  1:26  JAOC  TGTS  simultaneously  changed  the  JTF,  SOF,  LCC  and  MCC  blocks  green  I  the 
JTST  display.  This  appears  as  a  pro  fonna  action  without  any  operational  significance. 

3.  ADOCS 

The  E-2C  ADOCS  never  received  the  mission 

The  infonnation  about  the  mission  is  not  consistent  between  the  Fires  and  JTST  histories.  For 
example  the  JTST  History  shows  the  JAOC  TGTS  first  paired  the  target  with  ATO  call  sign 
Hornet  21  at  1:22.  Both  histories  show  the  target  paired  with  ATO  call  signs  LOITER07  and 
HORNET65  at  1:56  and  3:43  respectively.  The  JTST  shows  the  target  type  was  refined  from 
SCUD  D  to  SCUD  D  camouflaged  at  1 :38.  This  change  does  not  appear  in  the  Fires  History. 
For  the  JFMCC/XP  ADOCS  fires  is  the  primary  tool  for  prosecution  of  TSTs.  JTST  is  a 
collaboration  tool  to  provide  Situational  awareness  to  all  Components  of  the  status  of  TSTs. 
They  should  contain  the  same  information  and  changes  in  one  Manager  should  automatically 
update  the  other 

The  color  changes  to  the  TCT  block  recorded  in  Fires  Mission  History  are  not  internally 
consistent  and  not  consistent  with  the  ADOCS  Fires  displays.  The  changes  reported  in  the 
Mission  History  are  shown  in  Table  B2.2. 

Table  B2.2  Color  changes  to  the  TCT  Block 


Agent 

Time 

Color  Change 

JAOC  SIDO 

1:16 

yellow  to  green 

JAOC  TGTS 

1:27 

white  to  green 

JAOC  TGTS 

1:29 

green  to  yellow 

The  first  change  at  1:16  should  have  started  with  white,  the  second  change  at  1 :27  should  have 
started  with  the  existing  state  (green).  The  final  state  of  both  the  BLR  and  Newport  ADOCS 
displays  show  the  state  of  the  TCT  block  as  green  rather  than  yellow  (see  Table  B2.3).  These 
inconsistencies  may  be,  at  least  in  part,  a  result  of  ADOCS  latencies  but  some  could  be 
attributable  to  events  not  logged  in  the  mission  history. 
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Table  B2.3.  Final  Mission  state  from  Different  ADOCS  sources 


Source 

TCT 

XPA 

E2X 

DDX 

ANZ 

ADC 

WRD 

FRD 

BDA 

Mission  History 

Y 

Y 

Y 

G 

Mission  Coordination: 
Fires  display  BLR 

G 

Y 

Y 

G 

Mission  Coordination: 

G 

Y 

Y 

G 

Fires  display  Newport  _ _ _ _ _ _ _ _ _ 

4.  Timeline  Actions  and  Events 

00:41  ADOCS  Fires  Mission  History.  Nomination  received  in  ADOCS  from  TES-N 
00:43  ADOCS  Fires  Mission  History.  JIC  RFI  ASST  refines  target  type  to  SCUD  D  and 
modifies  the  NLT  time. 

00:44  ADOCS  Fires  Mission  History.  Nomination  promoted  to  JTST. 

00:44  ADOCS  Fires  Mission  History.  BLR  sets  XPA  to  yellow  indicating  the  mission  is 
acknowledged  and  being  worked. 

[00:50]  IRC.  JTFTSTCOORD  <TST_LNO>  JFMCC/XP  -  zoom  in  on  ADOCS  once  FIND  on 
MAP.  TB0051  plots  on  FDM! 

[00:52]  IRC.  JTF  TST  COORD  <TST_LNO>  XP/JFMCC  -  pis  work  best  TOT  for  Hornet21 
IOT  engage  TB005 1  and  for  BDA  gameplan 

[00:53]  IRC.  JTFISRCOORD  <TST>  WRT:  TB0051  we  need  collection  for  PID 
[00:57]  IRC.  JTF  ISR  COORD  <TST>  WRT:  TB0051  what  was  the  source  of  INTEL  on  this? 
[00:58]  IRC.  JTF  ISR  COORD  <TGT_OFF>  TSTLNO  -  the  imagery  of  the 
CAMOFLOUGED  Scud  is  in  the  ETF 

[00:58]  IRC.  JTF  TST  COORD  <TST_LNO>  XP/JFMCC:  PLS  work  a  best  TOT  for  Hornet21 
IOT  eventually  engage  TB005 1  and  to  coord  BDA  w/  U2.  TCT  block  in  Fires  Mgr  is 
YELLOW.  NOT  cleared  yet  to  engage! 

[01:07]  IRC.  JTF  ISR  COORD  <TST_LNO>  E2C-5:  Looking  for  TOT  for  Hornet21  IOT 
engage  TB005 1  and  to  work  BDA  coord.  Pis  pass  via  chat. 

[01:08]  IRC.  AIROPS  <E2C-5>  looking  for  TOT  for  Hornet21  to  engage  TB0051 
[01:09]  IRC.  AIR  OPS  <E2C-5>  Tacair  you  there? 

[01:09]  IRC.  JTF  ISR  COORD  <E2C-5>  attempting  to  establish  coimns  with  TACAIR 
[01:09]  IRC.  JTF  TST  COORD  <TST_LNO>  JIC:  Any  chance  of  getting  geo-refinement  on 
TB005 1?  If  so  pis  enter  in  Tgt  Data  tab  (JTST  Mgr) 

[01 : 12]  IRC.  JTF  TST  COORD  <TST_LNO>  ALCON:  Couldn’t  wait.  Set  TOT  for  TB005 1  of 
0135Z 

[01 : 12]  IRC.  AIR  OPS  <XP_E2X>  hold  up  on  that  who  gave  you  tasking  for  TB005 1 
[01:13]  IRC.  AIR  OPS  <E2C-5>  TST  LNO 

[01:13]  IRC.  AIR  OPS  <E2C-5>  I  don’t  have  TB005 1  in  LAWS  anyway 

[01:13]  IRC.  JTF  ISR  COORD  <E2C-5>  I  don’t  show  TB005 1  in  LAWS 

[01:13]  IRC.  JTF  ISR  COORD  <TST_LNO>  E2C-5  it’s  in  both  Fires  Mgr  and  JTST  Mgr. 

Couldn’t  wait.  Set  notional  TOT  for  Hornet21  of  0135Z 

[01 : 14]  IRC.  JTF  ISR  COORD  <E2C-5>  TACAIR  is  having  computer  problems 

[01 : 14]  IRC.  JTF  ISR  COORD  <E2C-5>  we  are  waiting  for  them  to  fix  their  issues  and  get 

aircraft  launched  for  this  event 
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[01:15]  IRC.  JTFISRCOORD  <TST>  WRT:  TB005 1  we’ll  be  requesting  post-strike  BDA  on 
target  w/in  30  minutes  of  TOT  which  is  0135Z. 

[01:16]  IRC.  JTF  ISR  COORD  <E2C-5>  are  you  planning  on  hitting  with  with  other  assets? 
[01:16]  IRC.  JTF  ISR  COORD  <E2C-5>  have  you  coordinated  with  XP? 

[01:16]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  copy  BDA  on  TB005 1 
[01:16]  IRC.  JTF  ISR  COORD  <E2C-5>  I  don't  have  TACIAR  to  task  at  the  moment 
1:05  ADOCS  JTST  Collection  Request  tab.  U2  tasked  to  remain  on  station  for  BDA 
1:16  ADOCS  Fires  Mission  History.  JAOC  SIDO  changes  ADC  to  green  indicating 
deconfliction  complete. 

1:16  ADOCS  Fires  Mission  History.  JAOC  SIDO  changes  TCT  block  to  green  indicating  the 
target  is  a  confirmed  TST. 

1:16  ADOCS  Fires  Mission  History.  JAOC  SIDO  changes  the  E2X  block  to  yellow  indicating 
mission  assignment. 

1:22  ADOCS  JTST  Mission  History.  JAOC  TGTS  pairs  mission  with  ATO  call  sign 
HORNET2 1 . 

1:26  ADOCS  JTST  Mission  History.  JAOC  TGTS  simultaneously  changed  the  JTF,  SOF,  LCC 
and  MCC  blocks  green. 

1:38  ADOCS  JTST  Mission  History.  JAOC  TGTS  refines  target  type  to  SCUD  D  camouflaged. 
[01 :43]  IRC.  JTF  ISR  COORD  <E2C-5>  looks  like  we  have  TACAIR  under  our  control  and 
are  standing  by  for  tasking 

[01:53]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  ISR  reports  no  strike  in  area.  TEL  reported  as 

packing  up  and  preparing  to  depart.  ETD  is  10  minutes.  UAV1  to  RTB  f 

[01:54]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  UAV1  RTBing  to  EOM 

[01:54]  IRC.  JTF  ISR  COORD  <E2C-5>  so  we’re  going  to  let  him  pack  up  and  move? 

[01:55]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  unless  you  can  roll  something  in  10  minutes, 
was  there  ever  a  MISREP  from  LOITER07? 

[01:55]  IRC.  JTF  ISR  COORD  <E2C-5>  is  the  target  in  LAWS? 

[01:56]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  target  is  in  ADOCS 

[01:56]  IRC.  JTF  ISR  COORD  <E2C-5>  ok,  what  is  the  target  number 

[0 1:56]  IRC.  JTF  ISR  COORD  <JFN_J2_OP>  TB005 1 

[01:56]  IRC.  JTF  ISR  COORD  <E2C-5>  don’t  show  that  in  my  target  list 

[01:57]  IRC.  JTFISRCOORD  <E2C-5>  if  you  pass  location  I  could  investigate  options,  but 

that  would  be  outside  of  LAWS 

1:43  ADOCS  Fires  Mission  History.  JAOC  TGTS  pairs  mission  with  ATO  call  sign  LOITER07. 

2:00  ADOCS  JTST  Target  data  tab.  Predator  on  station  1:05  to  1:50  and  did  not  see  any 
detonation  in  vicinity  of  target.  Reported  target  was  preparing  to  depart  site  at  1:45.  Predator 
returning  to  base. 

02:41.  NLT  time. 

3:30  ADOCS  Fires  Mission  History.  JAOC  TGTS  pairs  mission  with  ATO  call  sign 
HORNET65 
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Annex  B3  -  Nomination  AB5027 


1.  Timeline 

This  was  a  vehicle  convoy  nominated  by  the  Blue  Ridge  ADOCS  on  April  29  GMT  (April  30 
experiment  day).  The  target  was  engaged  by  the  vANZAC  with  four  ERGM. 

Table  B3.1  AB5027  Timeline 


Event 

Time 

Nomination  received  in  ADOCS 

23:42 

WTP  to  ANZAC  and  ERGM 

23:47 

Begin  strike  planning  (TCT  =yellow) 

Not  done 

Target  confirmed  TST 

Not  done 

Deconfliction  initiated 

Not  done 

Deconfliction  complete 

Not  done 

ANZAC  assigned  mission 

23:47(1) 

XP  acknowledges  mission 

00:29(1) 

ANZAC  acknowledges  mission  assignment 

01:07  (2) 

ANZAC  accepts  mission 

01:13  (3) 

XP  acknowledges  mission  acceptance 

01:15 

XP  authorizes  engagement 

01:16 

ERGM  fired 

01:19 

Notes  to  table: 

(1) .  These  events  appear  in  the  wrong  sequence. 

(2) .  This  is  IRC  statement  from  ANZAC  that  they  turned  the  ANZ  block  blue  in  their 
display.  This  does  not  appear  in  the  FBE  net  ADOCS. 

(3)  This  action  was  taken  by  BLR  on  behalf  of  ANZAC. 

The  interval  between  receipt  of  the  nomination  in  ADOCS  and  the  impact  of  the  rounds  was  1 
hour  and  46  minutes.  No  NLT  time  was  specified  for  this  target. 

The  mission  was  not  promoted  to  the  JTST 

It  was  never  defined  if  the  convoy  was  moving  or  stationary.  Since  it  was  WTP  to  ERGM  the 
presumption  is  that  it  was  stationary. 

The  event  timeline  IRC  entries  show  detailed  reporting  regarding  the  color  block  changes  that 
are  being  made  to  the  ADOCS  display  (e.g.,  see  the  interval  1 :07  -1 : 12).  This  is  attributable,  in 
part,  to  uncertainty  among  some  participants  about  the  TST  procedures  and,  in  part,  to  the  lack 
of  confidence  in  ADOCS  to  accurately  reflect,  in  a  timely  manner,  the  operator  block  actions  to 
all  ADOCS  workstations.  These  detailed  communications  result  in  an  expansion  of  the 
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engagement  timeline  and,  in  effect,  make  ADOCS  redundant  -  all  the  coordination  actions 
appear  to  be  occurring  in  chat  and  ADOCS  becomes  unnecessary. 


The  table  below  gives  the  times  of  ADOCS  block  actions  reported  in  chat  compared  to  the  times 
of  block  actions  reported  in  the  ADOCS  Mission  History.  The  time  differences  indicate 
approximately  a  four  minute  difference  in  the  clocks  used  to  timestamp  the  IRC  and  Mission 
History  events. 

Table  B3.2.  Time  Correspondence  of  IRC  and  ADOCS  Mission  History  Actions 


Time  of  Action 

Action 

in  IRC 

in  History 

Comment 

ANZ  block  W  to  Y 

NA 

23:47  01:07 

ANZ  block  Y  to  B 

01:07 

Does  not  occur 

ANZ  block  to  G 

01:09 

01:13 

History  shows  W  to 

G 

XPA  block  W  to  Y 

00:29 

00:29 

XPA  block  Y  to  B 

01:11 

01:15 

XPA  block  B  to  G 

01:12 

01:16 

FRD  Y  to  G 

01:14 

01:19 

Color  codes:  W=  white,  B=blue,  Y  =yellow,  G  =  green 

Because  the  FBE  net  and  Coalition  net  are  disconnected,  communications  must  be  manually 
transferred  from  one  net  to  the  other.  For  example  the  FBE  net  reports  at  1:10  that  the  XPA 
block  is  being  turned  blue.  That  message  was  introduced  into  the  Coalition  net  IRC  at  1:17.  The 
lack  of  an  automated  filter  (e.g.  ISSE  Guard  )  for  IRC  extends  the  engagement  timeline. 

2  TTp 

The  TTP  step  where  the  shooter  turns  his  block  green  to  acknowledgement  assignment  of  the 
mission  was  not  executed.  In  addition  the  following  TTP  procedures  were  neglected  for  this 
mission: 

No  TCT  action 
No  deconfliction  action 
No  georefinement  action 

In  the  BLR  ADOCS  Mission  History  no  actions  were  reported  as  executed  by  ANZAC.  All  those 
actions  which  should  have  been  executed  by  ANZAC  were  carried  out  on  the  BLR  (e.g.  BLR 
JOC  accepts  mission  for  ANZAC  at  1:13).  The  IRC  chat  shows  that  the  ANZAC  was  executing 
the  required  actions  (see  timeline  at  1 :07  and  1:10)  but  it  appears  that  these  events  were  not 
making  it  through  Radiant  mercury  to  the  FBE  net.  The  ADOCS  TTP  promulgated  on  May  1 
(see  Table  7)  has  the  BLR  putting  into  ADOCS  the  required  ANZAC  actions  on  receiving  the 
IRC  communications  requesting  those  actions  from  the  ANZAC.  It  is  presumed  this  TTP  was 
created  to  circumvent  Radiant  Mercury. 
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3.  ADOCS 


Table  B3.3  Final  state  for  Mission  AB5027  from  Different  ADOCS  sources 


Source 

TCT 

XPA 

E2X 

DDX 

ANZ 

ADC 

WRD 

FRD 

BDA 

Mission  History 

G 

G 

G 

Mission  Coordination: 
Fires  display  BLR 

G 

G 

G 

Mission  Coordination: 
Fires  display  Newport 

G 

G 

The  information  provided  by  the  ADOCS  coordination  blocks  is  sometimes  inconsistent.  The 
IRC  communications  between  1 :05  and  1 :07  indicates  the  ANZ  block  in  ADOCS  is  green  in 
Australia,  green  and/or  yellow  in  Newport,  white  on  the  BLR  while  the  ADOCS  Mission 
History  indicates  it  should  be  yellow.  The  end  state  of  the  engagement  also  illustrates 
inconsistency  in  the  ADOCS  data  (Table  B3.3).  The  Mission  History  indicates  that  the  final 
state  of  the  XPA,  ANZ  and  FRD  blocks  should  be  green,  the  Blue  Ridge  ADOCS  display  shows 
the  XPA,  WRD  and  FRD  blocks  green,  the  Newport  ADOCS  display  shows  XPA  and  FRD 
green.  Other  ADOCS  anomalies  are  alluded  to  in  the  IRC  comments  at  1:07  and  1:22-1:23. 
These  inconsistencies  make  it  impossible  to  detennine  what  actually  occurred  and  defeat  the  use 
of  ADOCS  as  a  Fires  planning  and  coordination  tool. 

Table  B3.4  illustrates  an  inconsistent  series  of  ANZ  block  actions.  The  fact  that  two  different 
agents  changed  the  block  white  to  yellow  is  not  explicable  unless  the  action  by  the  first  agent 
had  not  been  received  by  the  second  agent.  A  possible  explanation  for  the  second  JOC  change 
from  white  is  an  intennediate  yellow  to  white  change  not  logged  in  the  Mission  History. 

Table  3.4  ANZAC  Block  Actions 


Agent 

Time 

Color  Change 

ADOCS  TECH 

23:74 

white  to  yellow 

JOC  STATION  3 

1:07 

white  to  yellow 

JOC  STATION  3 

1:13 

white  to  green 

4.  Timeline  Actions  and  Events 

April  29  GMT 

23:42.  ADOCS  Fires  Mission  History,  Fires  Targeting  Tab.  Mission  received  in  ADOCS.  The 
Mission  History  log’s  first  entry  is  23:47. 

23:47  ADOCS  Fires  Mission  History.  WTP  to  ANZAC  ERGM. 

23:47  ADOCS.  Fires  Mission  History.  BLR  sets  ANZ  block  to  yellow  which  is  defined  as 
mission  assigned  to  ANZAC. 

23:50.  IRC  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  ALCON  -  we  see  WTP  on 
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AB5027  -  awaiting  further  processes 


April  30  GMT 

00:29.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  XPA  block  yellow  indicating  the  mission 
is  being  worked. 

00:57.  IRC.  FIRESCOORD  (Coalition  channel).  <ADOCS_AS>  FYI  -  we  are  still  waiting  for 
XP  ANZ  to  say  that  they  have  turned  ANZ  Tab  yellow  (AB5027) 

[01:04]  IRC.  ANZACOPS  <XP_ANZAC>  We  are  now  working  AB5027.  Does  ANZAC 
acknowledge  the  mission.  I've  so,  please  acknowledge  via  chat  and  I  will  change  table  color  to 
blue. 

[01:05]  IRC.  ANZAC  OPS  <CO_ANZAC>  ANZ  green  in  AUS  and  NPT 

[01:05]  IRC.  FIRES  COORD  (Coalition  channel).  <CO_IKA_2>  His  ANZ  tab  is  yellow  on 

AB5027 

[01:06]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  ack  AB5027  ANZ  is  yellow 
[01:06]  IRC.  ANZAC  OPS  <XP_ANZAC>  ANZ  is  white  on  BLR. 

[01:07]  IRC.  ANZAC_OPS  <XP_ANZAC>  Fires  mission  manager  for  ANZ  tab  resets  to  white 
for  every  RMG  transmission.  The  work  around  is  for  ADOCS  operator  BLR  to  edit  tabs. 

01 :07.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  ANZ  block  yellow. 

[01:07]  IRC  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  will  turn  ANZ  to  blue 
[01:07]  IRC  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  ANZ  turned  to  blue 
[01:08]  IRC.  ANZAC  OPS  <XP_ANZAC>  I'm  turning  ANZ  tab  green  for  AB5027. 

[01:09]  IRC.  ANZAC  OPS  <XP_ANZAC>  ANZ  tab  is  green  for  AB5027. 

[01:10]  IRC.  ANZAC  OPS  <XP_ANZAC>  XP  ack  msn  acceptance  -  turning  XPA  blue 
[01:10]  IRC  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  ANZ  tab  green 
[01:11]  IRC.  ANZAC  OPS  <XP_ANZAC>  XPA  is  blue. 

[01: 12]  IRC.  ANZAC  OPS  <XP_ANZAC>  XP  auth  engagement  -  turning  XPA  green. 

[01:12]  IRC.  ANZAC  OPS  <CO_ANZAC>  rgr-will  engage 

01:13.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  ANZ  block  green  indicating  mission 
accepted.. 

[01:14]  IRC  FIRES  COORD  (Coalition  channel).  <CO_IKA_2>  XP  turning  ANZ  green  for 
AB5027 

[01:14]  IRC.  ANZAC  OPS  <CO  ANZAC>  Shot  over.  WRD  Green,  FRD  White 
[01: 14]  IRC.  ANZAC  OPS  <XP_ANZAC>  Rgr.  Changing  FRD  tab  green. 

[01:15]  IRC.  ANZAC  OPS  <XP  ANZAC>  FDR  Green,  BDA  Yellow  -  Mission  complete 
01:15.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  XPA  block  blue  indicating 
acknowledement  of  mission  acceptance. 

[01:16]  IRC  FIRES  COORD  (Coalition  channel).  <CO_IKA_2>  ANZ  green  from  XP 
01:16.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  XPA  block  green  -  cleared  to  engage. 
[01:17]  IRC.  FIRES  COORD  (Coalition  channel).  <CO_IKA_2>  XP  turning  XPA  blue 
[01:17]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  why?  5  is  XP  turns  ANZ 
blue 

[01 : 18]  <  IRC.  FIRES  COORD  (Coalition  channel).  CO_IKA_2>  XPA  Green-you  may  engage 

[01:19]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  rgr  engaging 

[01:19]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  shot  -  over 

[01:19]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  ab5027  wrd  green  frd  white 
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01:19.  ADOCS  Fires  Mission  History.  BLR  JOC  turns  FRD  block  green 
[01:21]  IRC.  FIRESCOORD  (Coalition  channel).  <CO_IKA_2>  rgr.  XP  shows  MC 
[01:22]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  wrd  white  frd  green  here 
[01:22]  IRC.  FIRES  COORD  (Coalition  channel).  <DJS>  ANZAC  C2  rgr  That  was  weird 
WRD  GRN,  FRD  WHT,  BDA  GRY  to  WRD  WHT,  FRD  GRN,  BDA  GLD 
[01:23]  IRC.  FIRES  COORD  (Coalition  channel).  <ADOCS_AS>  we  see  the  same  here 
[01:23]  IRC.  FIRES  COORD  (Coalition  channel).  <DJS>  rgr  .  possibly  a  hiccup  due  to  BLR 
COMMS  TU  B4 

[01:27]  IRC.  GISRCISR  (Coalition  channel).  <GISR-AS>  watch  for  impact  of  ergm  for  bda 
assessment  on  convoy,  tgt  ab5027 

[01:28]  IRC.  GISRC  ISR  (Coalition  channel).  <ANZAC_C2>  splash  out 

[01:30]  IRC.  GISRC  ISR  (Coalition  channel).  <UAVContro>  SPOTTER  camera  view  of  DEAD 

lxtruck  TGT  ab5027  —  COAL 

Annex  B4  -  Nomination  GX  0321 

l.Timeline 

GX0321  was  a  May  1  nomination  of  a  Field  artillery  target  by  the  DDX  GISRC.  The  target  was 
prosecuted  with  an  ALAM  by  the  ANZAC.  Table  B4.1  shows  the  critical  timeline  events.  All 
actions  and  IRC  communications  related  to  the  GX0321  engagement  are  listed  in  Section  4. 


Table  B4.1  GX0321  Timeline 


Event 

Time 

Nomination  sent  from  DDX 

2:00? 

Nomination  received  in  ADOCS 

2:43 

Nomination  promoted  to  JTST 

3:10 

Begin  strike  planning  (TCT  yellow) 

No  done 

XP  acknowledges  mission 

3:18 

WTP  to  ANZAC 

3:34 

ANZ  assigned  mission 

3:36 

ANZ  acknowledges  mission 

3:36(1) 

ADC  initiates  deconfliction 

3:37 

Deconfliction  completed 

Not  done 

ANZ  accepts  mission 

3:46(1) 

XP  acknowledges  mission  acceptance 

3:46 

XP  authorizes  engagement 

3:47 

ALAM  Fired 

3:50 

Impact 

3:51 

Confirm  as  TST 

4:32  (2) 

NLT  time 

4:46 

Notes  to  Table: 
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(1)  Action  taken  on  BLR  on  behalf  of  ANZAC 

(2)  Out  of  sequence.  The  target  was  confirmed  as  TST  only  after  the  engagement  was 
completed. 

There  is  long  interval  between  the  presumed  time  of  transmission  of  the  mission  from  GISRC 
and  its  receipt  by  ADOCS  and  a  substantial  delay  between  receipt  of  the  mission  in  ADOCS  and 
WTP.  Thereafter,  the  process  proceeds  relatively  quickly.  The  total  interval  between  receipt  of 
the  nomination  in  ADOCS  and  the  launch  of  the  weapon  is  67  minutes. 

The  nomination  was  received  in  ADOCS  with  CE  and  LE  values  set  to  1 .  These  values  appear 
in  the  Mission  History  but  do  not  appear  in  the  Mission  Coordination:  Fires  Targeting  tab.  The 
nomination  was  based  on  UAV  imagery  so  this  level  of  accuracy  is  unrealistic.  There  is  no 
indication  that  the  UAV  imagery  was  sent  to  PTW  for  georefinement  although  such  an  action 
would  help  account  for  the  long  delay  in  the  receipt  of  the  nomination  at  ADOCS.  If  the  shooter 
took  the  provided  target  position  LE  and  CE  at  face  value  the  accuracy  of  the  coordinates  was 
more  than  adequate  to  the  needs  of  the  ALAM  precision  munition.  However,  at  the  time  of  fire 
the  shooter  announced  (3:50)  he  didn’t  know  or  care  if  the  target  had  been  georefined. 

The  details  of  the  timeline  are  blurred  by  the  fact  that  system  times  are  not  synchronized.  A 
comparison  of  the  same  events  in  the  FBE  net  IRC  log  and  the  ADOCS  Mission  History  shows 
the  events  are  2-3  minutes  later  in  ADOCS.  For  example,  IRC  reports  the  ANZ  tab  is  blue  at 
3:38,  the  Mission  History  log  reports  it  blue  at  3:36.  There  has  been  no  attempt  to  synchronize 
the  times  derived  from  different  sources  in  Table  B4.1. 

The  target  nomination  was  promoted  to  the  JTST  Manager  at  03:10.  Since  the  target  was 
nominated  and  executed  within  the  JFMCC,  the  appearance  in  the  JTST  was  not  required  for 
execution  but  for  cross-Component  situational  awareness.  The  JTST  Mission  History  files  do 
not  exist  in  FBE-K  for  May  1  and  2. 

2. TTP 

Because  the  FBE  net  IRC  and  Coalition  net  IRC  are  not  connected  communications  are  manually 
recreated  in  one  from  the  other.  The  time  lag  is  approximately  seven  minutes 

The  deconfliction  was  never  completed  but  the  mission  was  nevertheless  fired. 

The  target  was  confirmed  as  TST  only  after  the  engagement  was  completed. 

A  precision  munition  was  fired  without  concern  for  georefinement. 

The  required  shooter  (ANZAC)  ADOCS  actions  were  performed  by  the  BLR  presumably  to 
circumvent  problems  with  the  ADOCS  -  Radiant  Mercury  interface 

3.  ADOCS 

At  2:00  Dahlgren  reported  it  would  nominate  GX023 1  shortly.  The  nomination  was  not  received 
in  ADOCS  until  2:46.  There  are  no  communications  relating  to  the  cause  of  this  delay.  The 
facts  that  at  3:13  DDX  reports  it  does  not  show  GX023 1  in  his  ADOCS  display  and  the 
Newport  ADOCS  log  does  not  show  GX023 1  suggests  ADOCS  communications  may  be  the 
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problem.  The  absence  of  GISRC  data  does  not  permit  the  detennination  of  the  actual  time  of  the 
nomination  transmission. 


The  ADOCS  Mission  History  indicated  the  BLR  turned  the  XPA  block  blue  at  03: 15.  supposedly 
indicating  XP  acknowledges  the  shooters  acceptance  of  the  mission.  This  is  erroneous  as  the 
chat  indicates  at  this  time  that  the  shooter  had  not  received  the  mission. 

There  are  multiple  examples  in  the  Mission  History  of  blocks  being  changed  from  colors  that 
they  do  not  hold.  For  example,  at  3: 15  XPA  changed  from  white  to  blue  (by  BLR  SPARE  4 
ADOCS  workstation).  The  next  recorded  action  for  that  block  show  it  being  changed  at  3: 18 
from  white  to  yellow  (by  the  BLR  JOC  STATION  3).  Two  possible  explanations  for  this:  there 
is  an  event  changing  the  block  from  blue  to  white  missing  from  the  Mission  History  log  or  the 
change  at  3 : 1 5  was  not  received  by  the  second  workstation  so  in  his  context  the  block  was  still 
white  . 

The  table  below  illustrates  inconsistencies  in  the  final  state  of  the  mission  display  based  on  the 
three  sources  indicated.  From  IRC  it  is  clear  the  mission  was  fired  but  in  none  of  the  ADOCS 
displays:  BLR  Fires,  BLR  JTST  and  Newport  Fires,  or  in  the  Fires  Mission  History  is  it 
indicated  the  mission  was  fired. 

Table  B4.2.  Final  State  of  the  GX0321  Mission  from  three  sources 


Source 

TCT 

XPA 

ANZ 

ADC 

WRD 

FRD 

Mission  History 

G 

G 

G 

R 

W 

W 

Mission  Coordination:  Fires  display  BLR 

G 

G 

W 

W 

G 

Y 

Mission  Coordination:  Fires  display  NPT 

Mission  does  not  appear 

4.  Timeline  Actions  and  Events 

[01:51]  IRC.  DDXUAVCNTRL  <Dahlgren>  when  ready,  pis  surv  artillery  in  vie  of  radars 
[01:51]  IRC.  DDX  UAV  CNTRL  <UAV2>  BAK  ok 

[01:53]  IRC.  DDX  UAV  CNTRL  <UAV2>  FA  site  contact  -  6xTUBES,  1-C2,  VIC  150356N 
1453655E  DA  30  SP  ARTY 

[01:54]  IRC.  DDX  UAV  CNTRL  <UAV2>  FA  site  of  all  VEH(S)  in  current  view 
[01:54]  IRC.  DDX  UAV  CNTRL  <UAV2>  TGT  #? 

[01:55]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  can  you  zoom  over  left  lower  quads 
[01:56]  IRC.  DDX  UAV  CNTRL  <UAV2>  What  are  you  looking  for? 

[01:57]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  pis  zoom  to  PID  veh  lower  left  quad? 

[01:57]  IRC.  DDX  UAV  CNTRL  <UAV2>  The  last  tube  or  truck  in  current  view? 

[01:58]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  just  crossing  crosshair  x  axis  now 

[01:59]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  got  it.  Thanks 

[0 1 :59]  IRC.  DDX  UAV  CNTRL  <UAV2>  FREEZE  ON!!!!!!!!!!!!!!!! 

[01:59]  IRC.  DDX  UAV  CNTRL  <UAV2>  Releasing 

[01:59]  IRC.  DDX  UAV  CNTRL  <UAV2>  TGT  #?  for  FA  site?????????????????????????? 
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[02:00]  IRC.  DDXUAVCNTRL  <Dahlgren>  GX0321  -  will  send  out  nom  shortly 
02:43.  ADOCS.  Fires  targeting  tab.  Mission  recived  in  ADOCS.  Mission  History  gives  a  time 
of  2:46. 

[02:44]  IRC.  DDX_UAV_CNTRL  <Dahlgren>  can  we  get  overview  of  Batt  with  all  7  FAs? 
[02:45]  IRC.  DDX  UAV  CNTRL  <UAV2>  on  screen  now 

[02:46]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  can  you  move  away  fm  coast  to  get  lower  left 
quad  but  within  overview? 

[02:46]  IRC.  DDX  UAV  CNTRL  <UAV2>  will  this  work? 

02:46  ADOCS.  Fires  Mission  History.  DDX  GISRC  nomination  received  in  ADOCS.  The 

Targeting  tab  reports  the  time  received  is  02:43 

[02:50]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  closer  in  pis 

[02:51]  IRC.  DDX  UAV  CNTRL  <UAV2>  is  this  close  enough? 

[02:52]  IRC.  DDX  UAV  CNTRL  <Dahlgren>  good  for  overview  -  need  lower  left  quad  for  PID 
on  those 

03:10  ADOCS.  Fires  Mission  History.  BLR  JOC  promotes  nomination  to  JTST  Manager. 
[03:13]  IRC.  MARITIMEOPS  <XP_DDX>  where  did  GX0321  come  from? 

[03:15]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP...  DDX  does  not  show  GX0321  in  ADOCS. 
03:15.  ADOCS.  Fires  Mission  History.  BLR  changes  XPA  block  from  white  to  blue.  This  is  an 
inappropriate  action. 

03:18.  ADOCS.  Fires  Mission  History.  BLR  JIC  Air  IPB  changes  XPA  block  from  white  to 
yellow  indicating  XP  acknowledges  and  is  processing  the  mission. 

[03:29]  IRC.  ANZAC_OPS  <XP_ANZAC>  Stby  -  We  have  a  TST.  GX0321.  Let's  run  this  one 
to  ground  before  DV's. 

[03:29]  IRC.  TECHNIC AL  COORD  <vDDXSHREK>  BLRDJ  -  do  you  have  a  tgt  GX0321? 
[03:32]  IRC.  ANZAC_OPS  <XP_ANZAC>  ANZAC  -  You  have  WTP  ANZAC-ALAM  on 
GX0321  at  0335z. 

[03:33]  IRC.  ANZAC_OPS  <XP_ANZAC>  Msn  asgn  to  ANZAC,  XPA/ANZ  is  Green/Green. 
[03:33]  IRC.  TECHNICALCOORD  <BLR_DJ>  i  saw  it  come  in  but  don’t  see  it  now 
[03:34]  IRC.  TECHNICAL  COORD  <BLR_DJ>  ohh  ok  i  c  it  now 
03:34  ADOCS.  Fires  Mission  History.  BLR  WTP  GX0321  to  ANZAC  and  ALAM 
[03:34]  IRC.  ANZACOPS  <XP_ANZAC>  ADC  rgr  up  red.  Continue  with  msn  planning, 
expect  deconflict  by  time  of  engagement. 

[03:34]  IRC.  ANZAC_OPS  <XP_ANZAC>  VANZAC  pis  ack  msn 

[03:36]  IRC.  ANZAC  OPS  <XP_ANZAC>  GX0321  -  Field  Artillery.  Do  you  see  it.  It’s  a  TST. 
[03:36]  IRC.  ANZAC  OPS  <CO  ANZAC>  Yes-we  have  GX0321 

03:36.  ADOCS.  Fires  Mission  History.  BLR  JOC  changes  ANZ  block  from  white  to  yellow 
indicating  the  mission  is  assigned  to  the  ANZAC 

03:36.  ADOCS.  Fires  Mission  History.  BLR  JOC  changes  XPA  block  from  blue  to  yellow. 
Inconsistent  action 

03:36.  ADOCS.  Fires  Mission  History.  BLR  JOC  turns  ANZ  block  blue  indicating  the  shooter 
has  acknowledged  the  mission. 

03:37.  ADOCS.  Fires  Mission  History.  BLR  changes  ADC  block  to  red  indicating 
deconfliction  pending. 

[03:37]  IRC.  ANZAC_OPS  <XP_ANZAC>  Rgr  -  awaiting  your  ack  of  msn. 

[03:38]  IRC.  ANZAC  OPS  <CO_IKA_l>  Rgr,  ANZAC  ack  msn 
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[03:38]  IRC.  ANZAC_OPS  <XP_ANZAC>  Rgr  -  ANZ  tab  is  blue. 

[03:39]  IRC.  FIRESCOORD  (Coalition  channel)  <CO_IKA_l>  XP  is  stating  that  you  have 
WTP  ANZAC-ALAM  on  GX0321  at  0335z 

[03:40]  IRC.  FIRES  COORD  (Coalition  channel)  <CO_IKA_l>  XP  states  that  msn  asgn’d 
ANZAC,  XPA/ANZ  is  Grn/Grn 

[03:40]  IRC.  ANZAC_OPS  <XP_ANZAC>  XP  awaiting  ANZAC  msn  acceptance. 

[03:40]  IRC.  ANZACOPS  <CO_IKA_l>  ANZAC  accepts  msn. 

[03:41]  IRC.  TECHSIM  (Coalition  channel)<Coalition>  UAVContro,  what  are  coords  for 
GZ0321 

[03:42]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  we  just  had  that  upgraded  to 
WTP  and  XPA  yellow 

[03:42]  IRC.  ANZAC  OPS  <CO_IKA_l>  Interrogative  step  1.  XP  turns  XPA  Tab  yellow? 
[03:43]  <  IRC.  ANZAC  OPS  XP_ANZAC>  Rgr  -  Looks  like  we  got  a  RMG  blast.  We  lost  our 
colors.  I  just  reset. 

[03:43]  IRC.  ANZAC_OPS  <XP_ANZAC>  XPA  blue  and  ANZ  green. 

[03:43]  IRC.  ANZAC_OPS  <XP_ANZAC>  XP  auth  VANZAC  engagement. 

[03:43]  IRC.  FIRES  COORD  (Coalition  channel)  <CO_IKA_l>  do  u  ack  msn? 

[03:44]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  yes  -  we  ack  the  msn 
[03:44]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  what  about  step  3? 

[03:45]  <  IRC.  FIRES  COORD  (Coalition  channel)  CO_IKA_l>  XP  shows  ANZ  blue 
[03:45]  IRC.  ANZAC  OPS  <CO_IKA_l>  ALAM  away  GZ0321. 

[03:45]  IRC.  ANZAC  OPS  <CO_IKA_l>  CONPT  and  ANZAC  has  wrd-grn,  frd-gold 
03:46.  ADOCS.  Fires  Mission  History.  BLR  JOC  turns  ANZ  block  green  indicates  the  ANZAC 
has  accepted  the  mission. 

03:46.  ADOCS.  Fires  Mission  History.  BLR  JOC  turns  APX  yellow  to  blue  indicating  XP 
acknowledges  mission  acceptance. 

[03:46]  IRC.  ANZAC_OPS  <CoalMike>  1  ALAM  away  from  ANZAC 
[03:46]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  ANZ  tab  green 
[03:46]  IRC.  TECH  SIM  (Coalition  channel)<ANZAC_C2>  GX0321  is  on  SAIPAN  ,.Stby  co¬ 
ords  for  GX032 1 

[03:46]  IRC.  TECH  SIM  (Coalition  channel)<ADOCS_AS>  coal-mike  -  next  strike  is  GX0321 
-  Field  Arty  -  1  X  ALAM  in  posn  1 50400. 68N  1453647. 62E.  Will  advise  when  firing 
03:47.  ADOCS.  Fires  Mission  History.  BLR  JOC  turns  XPA  block  from  yellow  to  green 
indicating  the  engagement  is  authorized. 

[03:49]  IRC.  FIRES  COORD  (Coalition  channel)  <CO_IKA_l>  XP  is  showing  XPA-blue, 
ANZ-gm 

[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  rgr  XPA  blue  here,  now  green 
[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <CO_IKA_l>  XP  authorizes  engagement 
[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <DJS>  FIRE! ! ! 

[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  was  tgt  geo  refined? 

[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <DJS>  don't  know,  don’t  car e/ 

[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  rgr  engaging 
[03:50]  IRC.  FIRES  COORD  (Coalition  channel)  <ANZAC_C2>  ALAM  away  GX  0321 
[03:51]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  bird  away 
[03:51]  IRC.  FIRES  COORD  (Coalition  channel)  <ADOCS_AS>  wrd  green  frd  gold 
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[03:51]  IRC.  ANZAC  OPS  <CoalMike>  splash  -  out 

4:32  ADOCS.  Fires  Mission  History.  BLR  turns  the  TCT  to  green  indicating  the  target  is  a 

confirmed  TST 

4:46  ADOCS.  NLT  time 


Annex  B5  -  Nomination  AA0368 
l.Timeline 

AA0368  is  a  May  1  GMT  (May  2  experiment  day)  nomination  of  a  CDCM  site  by  the  ANZAC 
ADOCS.  The  target  was  prosecuted  by  the  DDX  firing  a  TLAM.  Table  B5. 1  shows  the  critical 
timeline  events.  All  actions  and  IRC  communications  related  to  the  AA0368  engagement  are 
listed  in  Section  4. 

Table  B5.1  AA0368  Timeline 


Event 

Time 

Target  acquired 

21:52 

Nomination  received  in  ADOCS 

22:01 

Nomination  promoted  to  JTST 

22:01 

Begin  strike  planning 

22:01 

WTP  to  ANZAC  and  ERGM 

22:35 

Amend  WTP  to  DDX  and  TLAM 

22:38 

Target  confirmed  as  TST 

22:45 

XP  acknowledges  mission 

22:46 

ANZAC  reports  unable  to  engage 

22:48  (1) 

Deconfliction  initiated 

22:48 

DDX  mission  assignment 

Not  done  (2) 

DDX  ack  of  assignment 

Not  done  (2) 

TLAM  route  request  received  at  RPM 

22:56 

TLAM  route  sent  from  RPM 

22:58 

Deconfliction  complete 

23:12 

XP  authorizes  engagement 

23:12 

DDX  accepts  mission 

23:16 

XP  ack  mission  acceptance 

Not  done 

DDX  sets  fire  when  ready 

23:18 

TLAM  fired 

23:18 

Detonation 

23:24 

BDA  report 

23:28 

NLT  time 

03:59 

Notes  to  Table: 
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ADOCS  action  taken  by  BLR  on  behalf  of  ANZAC 


(1)  See  Section  2. 

The  interval  between  the  receipt  of  the  target  in  ADOCS  and  the  tiring  of  the  TLAM  was  one 
hour  and  17  minutes. 

ADOCS  time  stamped  events  about  3  minutes  after  the  events  were  reported  in  IRC. 

2  up 

The  ADOCS  DDX  actions  are  confused.  The  ADOCS  procedure  defined  in  Table  8  indicates 
the  shooters  block  should  be  turned  yellow  by  XP  when  the  mission  is  assigned.  In  this  case, 
there  is  no  action  on  the  DDX  ADOCS  block  taken  by  the  BLR  and  the  first  two  actions  by  the 
DDX  are  not  consistent  with  the  TTP. 

Table  5.2  DDX  Block  Actions 


Agent 

Time 

Color  Change 

DDX  SHOOTER  1 

22:48 

white  to  blue 

DDX  SHOOTER  1 

23:01 

blue  to  yellow 

DDX  SHOOTER  1 

23:16 

yellow  to  green 

XP  did  not  acknowledge  DDX  acceptance  of  the  mission.  This  is  probably  a  consequence  of  the 
fact  that  the  DDX  actions  were  confused. 

3.ADOCS 


Table  5.3.  Final  State  of  the  AA0368  Mission  from  three  sources 


Source 

TCT 

XPA 

DDX 

ANZ 

ADC 

WRD 

FRD 

BDA 

Mission  History 

G 

G 

G 

R 

G 

G 

G 

G 

Mission  Coordination:  Fires 
display  BLR 

G 

G 

G 

R 

G 

G 

G 

G 

Mission  Coordination:  Fires 
display  Newport 

G 

G 

G 

R 

G 

G 

G 

G 

In  this  instance  all  three  data  sources  agree  on  the  final  state  of  the  engagement 


4.Timeline  Actions  and  Events 

[21:46]  IRC.  GISRISR  (Coalition  channel)  <UAVContro>  New  Contact  —  Possible  DECOY 
SS21  VIC  151057N  1454302E  DA  21  -  COAL 

[21:46]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  DARK  Pattern  on  SS21 

[21:46]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  I  still  think  DARK  Pattern  MEANS 

DECOY  SS21  -  COAL 

[21:47]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Looking  for  support  Veh(s) 
searching 
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[21:48]  IRC.  GISRISR  (Coalition  channel)  <UAVContro>  New  contact  —  2nd  POSSIBLE 
DECOY  lxSS21  VIC  151026N  1454257E  DA  27  -  COAL 

[21:48]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Need  TGT#  for  1st  DECOY  SSS21 
[21:49]  IRC.  GISR  ISR  (Coalition  channel)  <GISR-AS>  1st  aa0366 
[21:49]  IRC.  GISR  ISR  (Coalition  channel)  <GISR-AS>  2nd  aa0367 

[21:49]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  1st  aa0366  for  151057N  1454302E, 
yes 

[21:50]  IRC.  GISR  ISR  (Coalition  channel)  <GISR-AS>  affirm 

[21:50]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  No  other  support  veh(s)  in  area, 
AGAIN  think  these  are  DECOY(s) 

[21:50]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Researching  area  for  Support  Veh(s) 
-  standby 

[21:51]  IRC.  GISR  ISR  (Coalition  channel)  <GISR-AS>  3rd  vehicle? 

[21:51]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  New  Contact  —  3rd  DECOY  SS21  -- 
VIC  151020N  1454256E  DA  28  -  -COAL 

[21:51]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  SPOTTER  VIEW 
[21:52]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  See  the  DARK  CAMO  pattern? 
[21:52]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Clouds  coming  in  and  out 
[21:52]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Waiting  for  TGT# 

[21:52]  IRC.  GISR  ISR  (Coalition  channel)  <GISR-AS>  aa0368 

22:01  ADOCS  .  Fires  Mission  History.  Nomination  received  in  ADOCS  from  BLR  JOCC. 

22:01  ADOCS  .  Fires  Mission  History.  BLR  JOCC  changes  TCT  block  from  white  to  yellow 
indicating  the  target  is  a  possible  TST  target. 

22:01  ADOCS  .  Fires  Mission  History.  BLR  JOCC.  Mission  promoted  to  the  JTST  Manager. 
[22:03]  IRC.  ANZAC_OPS<XP_ISR>  XP_AZAC:  request  imagery  for  AA0366/67/68  to  ID  as 
a  potential  TST 

[22:03]  IRC.  #FIRES_COORD  (Coalition  channel)  <ADOCS_AS>  AA0367/0368/0369  targeted 
[22:06]  IRC.  JTFISRCOORD  <TST>  JFN  J2  0P:  WRT:  AA0368  we’re  going  to  need 
imagery  for  PID  as  well  as  CDE  support  and  post-strike  BDA  once  target  is  PID  and  approved  as 
TST. 

[22:09]  IRC.  #FIRES_COORD  (Coalition  channel)  <ADOCS_AS>  FYI  -  have  now  targeted  5 
targets  via  ADOCS,  awaiting  WTP  by  XP 

[22:15]  IRC.  ANZAC_OPS  <XP_ANZAC>  We  see  AA0358,  66,  67,  68,  69,  70,  and  73. 

[22:22]  IRC.  JTF  ISR  COORD  <TST>  MCC:  AA0366,  AA0367,  AA0368  have  been  passed  to 
you;  awaiting  your  acknowledgement. 

22:35  ADOCS  .  Fires  Mission  History.  BLR  JOC.  WTP  to  ANZAC  and  ERGM 
22:38  ADOCS  .  Fires  Mission  History.  BLR  JOC.  WTP  changed  to  DDX  and  TLAM. 

22:45  ADOCS  .  Fires  Mission  History.  BLR  JOCC  changes  TCT  from  yellow  to  green 
indicating  target  is  confirmed  TST 

22:46  changes  XPA  block  to  yellow  indicating  XP  acknowledges  the  mission 

[22:46]  IRC.  GISR  ISR  (Coalition  channel)  <UAVContro>  Update  aa0368  DECOY  SS21  still 

there  —  lower  part  of  view 

22:48  ADOCS  .  Fires  Mission  History.  BLR  changes  E2X  block  blue. 

22:48  ADOCS  .  Fires  Mission  History.  BLR  changes  ANZ  block  red  indicating  ANZAC  is 
unable  to  engage. 
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22:48  ADOCS  .  Fires  Mission  History.  BLR  changes  ADC  block  red  indicating  deconfliction  is 
underway. 

[22:48]  IRC.  MARITIMEOPS  <XP_DDX>  DDx  TAO,  can  you  strike  AA0368 

[22:48]  IRC.  MARITIME  OPS  <XP_DDX>  IF  so  req  box  blue  on  DDX  to  tell  us  IAW  with  1 

May  process 

22:48  ADOCS  .  Fires  Mission  History.  DDX  turns  DDX  block  blue  to  acknowledge. 

22:5 1  ADOCS  .  Fires  Mission  History.  BLR  turns  E2  block  from  blue  to  white 
[22:51]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP...  DDX  req  confirm  AA0368. 

[22:51]  IRC.  MARITIME  OPS  <XP_DDX>  Also  if  assigned  msn  (WTP)  go  to  yellow 
[22:51]  IRC.  MARITIME  OPS  <XP_DDX>  Confirm  aa0368?  What  do  you  need  to  know 
22:56.  RPM.  TLAM  route  request  received. 

22:58  RPM.  TLAM  route  sent. 


[22:58]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP...  DDX  can  accept  AA0368. 

[22:58]  IRC.  MARITIME  OPS  <XP_DDX>  Block  just  changed  to  yellow  DDX 
[22:58]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP..  request  pennission  to  engage  AA0368 
23:01  ADOCS  .  Fires  Mission  History.  DDX  turns  DDX  block  from  blue  to  yellow  to  indicate 
acceptance? 

[23:02]  IRC.  MARITIME  OPS  <TAO_vDDX>  rgr  yellow  block  for  AA0368 
23:12  ADOCS  .  Fires  Mission  History.  BLR  turns  ADC  from  red  to  green  indicating 
deconfliction  complete. 

23:12  ADOCS  .  Fires  Mission  History.  BLR  turns  XPA  yellow  to  green  indicating  engagement 
is  authorized. 


[23:15]  IRC.  MARITIME  OPS  <TAO_vDDX>  XP...  DDX  Greyhound  away  AA  00368  TOF 
8:30 

23:16  ADOCS  .  Fires  Mission  History.  DDX  turns  the  DDX  block  yellow  to  green  indicating 
meaning  the  mission  is  accepted 

23: 18  ADOCS  Fires  Mission  History.  DDX  turns  the  WRD  block  green. 

23:18  ADOCS  Fires  Mission  History.  DDX  turns  the  FRD  block  green. 

23:23:46  SNN.  Detonation  report. 

23:28  ADOCS  Fires  Mission  History.  DDX  turns  the  BDA  block  green  with  the  comment  the 
target  is  destroyed. 

03:59  ADOCS  NLT  time. 
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Appendix  C  FBE-K  TECHNICAL  AFTER-ACTION  REVIEW 

This  Appendix  was  provided  by  Wayne  "Doc"  Sweitzer  of  Titan  Corporation 

Summary 

PURPOSE.  The  use  of  the  Joint  Fires  Network  (JFN),  and  in  particular  its  Tactical  Exploitation 
System  -  Navy  (TES-N)  subsystem,  to  support  Time  Sensitive  Targeting  (TST)  was  a  major 
focus  of  the  Sea  Strike  Initiative  in  Tandem  Thrust  2003  (TT03)  /  Fleet  Battle  Experiment  Kilo 
(FBE-K).  This  paper  recounts  the  technical  issues  encountered  during  TT03/FBE-K,  as  well  as 
functional  issues  that  had  a  significant  technical  impact,  and  makes  recommendations  for  future 
improvements. 

DEFINITIONS.  The  following  are  definitions  of  systems  terminology  used  in  this  paper: 

•  JFN  -  Joint  Fires  Network:  a  recent  name  change  for  NFN  which  is  little  more  than  a 
programmatic  attempt  to  indicate  that  NFN  is  now  a  joint  program  —  which  it  is  not. 

•  NFN  -  Naval  Fires  Network:  as  of  FBE-K  execution,  NFN  was  still  the  official  term  for 
the  “converged  architecture”  of  three  programs:  TES-N,  JSIPS-N,  GCCS-M. 
Unfortunately,  the  fonner  TES-N  program  office  (NAVSEA  PMS-454)  perpetuated  the 
use  of  the  tenn  “NFN”  to  refer  to  TES-N  only,  thereby  introducing  great  confusion  in  the 
Fleet  and  elsewhere  —  confusion  that  was  still  painfully  evident  during  TT03/FBE-K. 

•  TES-N  -  Tactical  Exploitation  System  -  Navy:  TES-N  is  an  immature  integration  (in 
systems  development  terms)  of  a  number  of  complex,  powerful  software  and  hardware 
applications  that  overwhelmingly  fall  in  the  functional  category  of  Intelligence, 
Surveillance,  Reconnaissance  (ISR). 

•  JSIPS-N  -  Joint  Service  Imagery  Processing  System  -  Navy:  aboard  USS  BLUE 
RIDGE  (BLR),  JSIPS-N  included  the  Precision  Targeting  Workstation  (PTW),  NIMA’s 
Image  Product  Library  (IPL),  and  the  connectivity  (via  Challenge  Athena  III)  with  the 
Joint  Concentrator  Architecture  (JCA)  IPL  located  at  the  Office  of  Naval  Intelligence 
(ONI)  in  Suitland,  MD. 

•  GCCS-M  -  Global  Command  and  Control  System  -  Maritime:  among  many  other 
things,  GCCS-M  is  the  “engine”  for  the  Common  Operational  Picture  (COP)  shared 
force-wide.  TES-N  is  supposed  to  be  an  important  contributor  to  the  COP;  it  is  not. 

•  ADOCS  -  Army  Deep  Operations  Coordination  System:  ADOCS  was  the  primary 
“intended  target”  of  TES-N  output,  in  the  form  of  ATI.ATR  target  nomination  messages. 
While  only  sometimes  included  in  even  the  loosest  use  of  the  tenn  “JFN”,  ADOCS 
(which  is  also  known  in  Navy  circles  as  “LAWS”)  is  the  only  real  connection  TES-N  / 
JFN  on  BLR  had  to  “fires”. 

•  AFSERS-MUSE  -  Air  Force  Synthetic  Environment  for  Reconnaissance  and 
Surveillance-Multiple  Unified  Simulation  Environment:  AFSERS-MUSE  was  a 
modeling  and  simulations  (M&S)  system  that  fed  TES-N  with  simulated  ISR  video  (e.g., 
from  a  simulated  UAV  or  simulated  P-3  AIP  aircraft),  and  with  simulated  U-2  still 
imagery  and  platform/sensor  telemetry.  Although  “MUSE”  and  “AFSERS”  are  virtually 
synonymous,  MUSE  was  commonly  used  during  TT03/FBE-K  execution  and  planning  to 
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refer  to  just  the  simulated  ISR  video  produced  by  M&S  Central  in  Simms  Hall,  Newport, 
RI.  (The  U-2  M&S  “pieces”  were  referred  to  as  “AFSERS-TENCAP”  —  see  below). 

•  AFSERS-TENCAP  -  Air  Force  Synthetic  Environment  for  Reconnaissance  and 
Surveillance-Tactical  Exploitation  of  National  Capabilities:  AFSERS-TENCAP  was 
the  term  commonly  used  during  TT03/FBE-K  execution  and  planning  to  refer  to  the  U-2 
M&S  “pieces”  (i.e.,  U-2  still  imagery  and  platform/sensor  telemetry),  produced  by  the 
AFSERS  system  on  board  USS  BLUE  RIDGE  (BLR)  and  sent  to  TES-N. 

•  ISR  UUV  -  Intelligence,  Surveillance,  Reconnaissance  Unmanned  Underwater 
Vehicle:  “ISR  UUV”  is  used  herein  to  refer  to  the  virtual  SSN  and  its  two  simulated  ISR 
UUVs  that  participated  during  the  FBE-K  FTX  as  ISR  “collectors”.  The  Naval  Undersea 
Warfare  Center  (NUWC)  provided  sophisticated  simulation  of  vSSN  and  ISR  UUV 
platform  behavior  and  ELINT/ESM  collection  and  reporting,  along  with  rudimentary 
COMINT  and  IMINT  “proof-of-concepf  ’  simulation  and  reporting. 

Highlights 

•  Remote  M&S  stimulation  of  TES-N  /  JFN  was  sufficient  for  familiarizing  C7F  Staff  with 
the  basic  processes  involved  in  using  TES-N  /  JFN  in  support  of  TST. 

•  Successful  demonstration  of  TST  Target  Folder  server  concept  as  common  repository  for 
relevant  TST  target  data. 

•  Gained  in-depth  insights  into  many  JFN  systems  issues,  myths  and  realities. 

•  All  simulated  Blue  ISR  assets  displayed  in  COP  simultaneously  with  appropriate  labels 
by  end  of  FTX. 


Technical  Accomplishments  &  Issues 

A.  SYSTEMS. 

1.  TES-N.  The  TES-N  suite  used  in  TT03  /  FBE-K  was  already  “organic”  to  USS 
BLUE  RIDGE  (BLR)  —  no  major  alternations  or  upgrades  were  done  specifically  for  TT03  / 
FBE-K,  although  the  system  software  had  just  recently  (Jan  or  Feb  2003)  been  upgraded  to  TES- 
N  version  5.0.  Other  systems/components  used  in  conjunction  with  TES-N  included: 

2.  JSIPS-N  /  PTW  (organic  to  BLR) 

3.  IPL  /  JCA  (organic  to  BLR) 

4.  GCCS-M  (organic  to  BLR) 

5.  ADOCS  (software  installed  on  BLR  organic  IT-21  PCs) 

6.  ISR-M  (organic  to  PACAF  AOC,  Hickam  AFB,  HI) 

7.  TES-N  RTC  (organic  to  USS  ESSEX) 

8.  M&S  systems,  including: 

a.  JSAF  (Newport  M&S  lab) 

b.  AutoSIGS  (Newport  M&S  lab) 

c.  ASSET  (Newport  M&S  lab) 

d.  AFSERS-MUSE  (Newport  M&S  lab) 

e.  Video  controller  /  video  remote  (Newport  M&S  lab  /  aboard  BLR) 

f.  AFSERS-TENCAP  (aboard  BLR) 

g.  ISR  UUV  (at  NUWC  Newport) 
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B.  M&S  FEEDS  INTO  TES-N. 


1.  Video: 

a.  ACCOMPLISHMENTS:  During  both  CPX  and  FTX,  simulated  ISR  video 
was  produced  by  AFSERS-MUSE,  fed  into  the  NWDC  video  controller  in  Newport,  distributed 
as  MPEG-4  to  BLR  via  the  FBE  WAN  (including  KuBand  SATCOM).  The  MPEG-4  stream 
was  converted  and  fed  by  the  NWDC  video  remote  server  on  BLR  as  analog  video  (RS-170)  into 
TES-N’s  video  switch,  which  then  presumably  re-digitized  the  video  for  distribution  to  any 
GENSER-level  TES-N  Multi-Function  Workstation  (MFWS)  [unable  to  confirm  precise  “inner 
workings”  of  TES-N  internal  video  distribution]. 

b.  ISSUES/COMMENTS: 

(1)  Video  Feed  Stability.  The  video  feed  into  TES-N  was  stable  and 
reliable  during  both  CPX  and  FTX,  aside  from  one  very  minor  issue:  the  BLR  video  remote 
server’s  display  properties  had  to  be  re-set  by  one  of  the  NWDC  Facilitators  (Sweitzer  or 
Meana)  to  800x600  or  higher  approximately  once  a  day,  normally  first  thing  in  the  morning  BLR 
time  (the  display  properties  would  somehow  revert  to  640x480  on  occasion  and  then  freeze  the 
display). 

(2)  Simulated  ISR  Video  “Command  and  Control”.  The  M&S  “pilots” 
who  were  “flying”  the  simulated  ISR  video  platforms  were  thoroughly  supportive  and 
professional.  Their  flexibility,  and  the  flexibility  of  their  M&S  systems,  allowed  NWDC 
Facilitators  on  BLR  the  latitude  to  respond  rapidly  to  changes  in  circumstances  and/or  FBE 
participant  requirements  when  needed.  On  only  a  few  occasions  there  was  confusion  introduced 
by  other  FBE  participants  (e.g.,  vDDX  at  Dahlgren)  as  to  who  had  “command  and  control”  over 
which  simulated  ISR  video  asset  when.  While  not  a  technical  issue  per  se  (and  probably  not  an 
unrealistic  situation  in  the  “real  world”)  this  underscored  the  importance  of  having  (and 
participants  adhering  to)  a  well-established  C2  structure  for  ISR  operations,  even  in  an 
experimental  environment.  Also,  the  initial  plan  to  coordinate  with  the  “pilots”  via  voice-only 
proved  to  be  unwieldy,  primarily  because  the  TES-N  video  screener(s)  did  not  have  exclusive 
access  to  an  IP  phone/headset  at  his/her  workstation,  and  as  such  had  to  coordinate  by  voice 
across  the  room  to  someone  (NWDC  Facilitator  in  lieu  of  an  ISR  operations  type)  who  was  on 
the  IP  phone  with  the  “pilot”.  By  early  in  the  CPX,  the  TES-N  FSRs  had  configured  TES-N’s 
IRC  chat  tool  to  allow  screeners  and  “pilots”  to  interface  directly  via  chat,  which  was  a  far 
superior  arrangement  from  the  screener’s  perspective  to  going  through  the  intennediary. 

(3)  TES-N  Video  Application.  The  TES-N  video  display  and  capture 
application  was  generally  reliable,  but  has  a  strange  software  bug  in  that  the  user’s  video  control 
icons  (e.g.,  start,  stop,  capture,  etc.)  do  not  display  upon  initially  opening  the  window  until  the 
user  moves  the  cursor  over  that  area  in  the  window  (i.e.,  on  the  border  between  the  video  frame 
itself  and  the  upper  edge  of  the  window). 

(4)  Video  Quality. 

(a)  As  viewed  on  TES-N  MFWS:  By  the  time  the  video  was 
displayed  on  the  TES-N  MFWS  (an  “A-to-D”  conversion  or  two  AFTER  leaving  the  video 
remote  server),  the  quality  of  the  video  simulation  was  barely  useable  for  the  purposes  of  having 
TES-N  users  “go  through  the  motions”  of  Time  Sensitive  Target  (TST)  detection  and 
identification.  For  instance,  the  NWDC  Facilitators  on  BLR  would  often  have  to  go  to  another 
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space  on  BLR  to  read  the  latitude/longitude  readout  on  the  video  remote  server  screen,  as  those 
same  numbers  were  illegible  on  the  TES-N  screen. 

(b)  Video  capture:  The  video  image  “chips”  captured  by  TES-N 
were  of  significantly  lower  quality  than  those  captured  from  the  same  source  by  the  GISRC 
workstations  used  in  the  FTX  in  Newport  and  Dahlgren,  as  evidenced  by  comparing  the  captured 
images  posted  to  the  TST  Target  Folder  Server  by  each  of  the  systems. 

(c)  Base  image  and  model  quality:  For  future  consideration,  even 
with  improved  TES-N  video  handling,  the  quality  of  the  simulated  video  used  in  FBE-K  would 
not  be  sufficient  for  any  type  of  analytic/targeting  experimentation  (beyond  just  “going  through 
the  process  motions”)  due  primarily  to  the  resolution  and  two-dimensional  nature  of  the  base 
imagery  used.  Three  supporting  points: 

[1]  For  instance,  when  zoomed  in  close  enough  to  support 
positive  identification  (PID)  of  the  TST,  the  background  of  base  imagery  became  so  blurred  as  to 
appear  solid,  thereby  losing  all  visual  context,  and  making  the  3-D  model  target  look  as  if  it  were 
“free-floating”  in  air  or  water. 

[2]  Furthermore,  the  combination  of  the  low  resolution  of 
the  available  base  imagery,  coupled  with  the  lack  of  features  that  are  easily  identified  at  coarse 
image  resolution  (e.g.,  cross-roads,  bridges,  population  centers)  on  the  Northern  Mariana  Islands 
(e.g.,  Rota,  Saipan,  Tinian),  was  insufficient  to  support  actual  “visual  point  transfer”  by  PTW 
operators  between  the  captured  video  images  and  the  Digital  Point  Positioning  Database 
(DPPDB). 

[3]  Finally,  while  the  three-dimensional  models  of  the  TST 
vehicles  and  other  equipment  are  good,  they  are  too  easy  to  pick  out  (initial  detection),  as  they 
“lay  on  top”  of  the  terrain  instead  of  being  part  of  it,  thereby  providing  a  false  sense  of  the  level 
of  difficulty  of  initial  TST  detection  with  a  video  sensor  (e.g.,  would  provide  false  results  in  any 
attempt  to  quantify  the  TST  timeline  if  measured  from  receipt  of  initial  “tipper”  indications  or 
before). 

(5)  Video  Platform/Sensor  Telemetry.  As  in  MC02/FBE-J,  TES-N  could 
not  do  any  parsing  or  processing  of  the  telemetry  data  provided  by  the  ISR  video  platform  M&S 
system  other  than  display  it,  on-screen,  “burned  in”  as  part  of  the  video  images  themselves.  This 
resulted  in  the  manual  entry  of  data,  particularly  latitude/longitude,  into  the  TES-N  target 
nomination  creation  template,  significantly  increasing  both  the  time  required,  and  the  risk  of  data 
entry  errors. 

2.  Imagery  via  JCA: 

a.  ACCOMPLISHMENTS:  During  both  CPX  and  FTX,  imagery  from  simulated 
national  and  other  sources  was  produced  in  NITF  format  by  the  AutoSIGS  system  at  M&S 
Central  in  Newport,  and  then  transferred  (FTP)  to  JCA’s  Command  IPL  located  at  ONI  in 
Suitland,  MD.  JCA  connectivity  (via  Challenge  Athena  III  SHF  SATCOM)  allowed  users 
aboard  BLR  to  access  the  JCA  IPL  (via  the  web-based  Quick  Query  or  Q2  application),  and  pull 
the  images  down  to  the  BLR  IPL.  From  there  they  could  be  accessed  by  either  PTW  or  TES-N, 
the  latter  of  which  could  pull  the  images  over  to  its  own  system  server,  and  process  the  NITF 
headers  to  register  the  images  in  its  DBO  (Database  Organizer)  application. 

b.  ISSUES/COMMENTS: 
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(1)  JCA  IPL  Access  and  Country  Codes.  There  were  two  major  hurdles 
to  successful  use  of  this  method  of  image  file  transfer:  (a)  the  long  and  difficult  process  of 
getting  procedures  and  pennissions  to  access  the  “real  world”  JCA  IPL  (technically  simple,  but 
“culturally”  complex);  and,  (b)  modifying  AutoSIGS  software  to  allow  production  of  NITF 
headers  with  a  country  code  of  something  other  than  the  default  “CC”  (in  this  case,  “CQ”  —  the 
NIMA  country  code  for  Northern  Marianas),  as  the  IPL  software,  both  at  JCA  and  on  BLR, 
requires  the  use  of  actual,  validated  country  codes  in  NITF  file  headers.  After  much 
coordination,  the  AutoSIGS  modifications  were  made,  proper  permissions  were  granted,  and 
JCA  IPL  access  procedures  were  developed  in  time  to  allow  smooth  operations  by  day  four  (17 
April  2003)  of  the  CPX,  after  which  there  were  no  significant  issues  encountered. 

(2)  AutoSIGS  Image  Quality.  As  with  the  simulated  video,  the  simulated 
imagery  quality  was  sufficient  for  analysts  to  run  through  proper  procedures  for  information  and 
process  flow  in  support  of  TST.  It  would  not,  however,  be  sufficient  for  any  experimentation 
involving  actual  imagery  analysis,  targeting,  or  battle  damage  assessment. 

3.  U-2  Dragon  Lady  simulation  (from  AFSERS-TENCAP  aboard  BLR): 

a.  ACCOMPLISHMENTS:  During  both  CPX  and  FTX,  attempts  were  made  to 
simulate  the  inputs  into  TES-N  that  would  come  from  a  U-2  Dragon  Lady  aircraft  if  it  were 
downlinking  directly  to  BLR  as  its  ground/surface  station.  These  inputs  fall  into  two  categories: 

(1)  Images.  Based  on  the  collection  tasking  in  the  U-2  mission  plan  given 
to  it  (more  on  this  in  the  “TES-N  Outputs”  section  below),  the  AFSERS-TENCAP  on  BLR 
would  FTP  two  images  per  collection  “event”  in  NITF  format  to  TES-N:  a  low-resolution  image 
to  the  TES-N  Screener  application,  and  a  high-resolution  image  of  that  same  area  of  coverage  to 
the  TES-N  DBO  application. 

(2)  Telemetry.  AFSERS-TENCAP  provides  a  data  stream  (UDP)  to  TES- 
N  that  tells  where  the  simulated  U-2  is  located  at  any  given  time,  based  upon  the  same  mission 
plan  referred  to  above  (and  in  “TES-N  Outputs”  section  below).  This  capability  worked  only 
briefly  during  TT03/FBE-K  (last  two  days  of  CPX)  because  of  a  number  of  complex  issues 
including  an  initial  lack  of  mission  plans,  an  initial  lack  of  a  required  software  script,  errors  in 
subsequent  mission  plans,  and  suspected  software  problems  in  TES-N  (addressed  elsewhere  in 
this  paper). 

b.  ISSUES/COMMENTS: 

(1)  Image  Screener’s  “Waterfall”.  Contrary  to  previous  belief,  there 
exists  no  capability  in  AFSERS-TENCAP  to  provide  the  “waterfall”  type  of  display  in  the  TES- 
N  Screener  application  that  one  would  get  from  a  live  U-2  aircraft’s  SAR  or  EO/IR  imaging 
sensors  in  “search”  (vs.  “spot”)  mode. 

(2)  Image  Quality.  The  base  imagery  used  by  AFSERS-TENCAP  of  the 
Northern  Marianas  was  a  mix  of  5-meter  and  1 -meter  resolution  imagery  stitched  together, 
providing  significantly  better  resolution  in  some  areas  (where  there  was  1 -meter  coverage)  than 
the  base  imagery  used  in  AutoSIGS  and  AFSERS-MUSE. 

(3)  Telemetry  Processing  Script.  To  receive  and  process  the  telemetry 
data  provided  by  AFSERS-TENCAP,  TES-N  needs  to  be  running  a  script  that  is  custom  built  for 
the  task,  and  one  that  is  apparently  not  part  of  the  standard  TES-N  version  5.0  software  build. 

The  TES-N  FSRs  on  BLR  were  unaware  of  any  such  script,  but  after  several  days  of  being 
convinced  such  a  script  existed,  and  then  checking  with  the  TES  Operational  Support  Facility  in 
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Baltimore,  MD,  they  were  able  to  install  and  run  the  script,  and  successfully  receive  and  display 
the  telemetry  during  the  last  two  days  of  the  CPX  (19-20  April  2003). 

(4)  AFSERS-TENCAP  simulated  SAR  imagery  was  illegible  by  TES-N. 
To  simulate  SAR  imagery,  AFSERS-TENCAP  simply  takes  EO  imagery  and  “degrades”  its 
resolution  using  various  techniques.  Unfortunately,  when  the  sim-SAR  imagery  was  received  in 
the  TES-N  Screener  application,  it  was  so  dark  as  to  be  totally  useless  to  the  imagery  screener 
analyst.  Even  when  saved  in  TES-N’s  DBO,  the  many  imagery  manipulation  tools  in  TES-N 
could  not  enhance  the  image  to  retrieve  any  type  of  useful  visual  information.  The  work-around 
was  to  have  the  simulated  U-2  fly  with  an  ASARS  sensor  (the  only  sensor  type  AFSERS- 
TENCAP  could  reliably  simulate),  and  yet  produce  EO  images  (NWDC  Facilitators  had  to  ask 
the  players  to  “pretend”  they  were  seeing  SAR,  and  therefore  could  “see  through”  the  cloud 
cover  that  “forced”  them  in  the  first  place  to  not  use  UAV  EO  video,  but  to  use  U-2  SAR 
imagery  instead). 


4.  ELINT/ESM: 


a.  ACCOMPLISHMENTS:  During  both  CPX  and  FTX,  attempts  were  made  to 
send  simulated  ELINT/ESM  from  various  M&S  sources  to  the  Tactical  Data  Dissemination 
System  (TDDS)  Network  Management  Center  (TNMC)  in  Washington,  DC,  to  be  put  onto  the 
TDDS  broadcast,  with  receipt  of  the  broadcast  on  BLR  being  via  organic  means,  and  processing 
of  exercise/experiment  ELINT  done  using  the  GALE  software  in  TES-N.  The  various  M&S 
ELINT/ESM  sources  and  their  success  were: 

(1)  JQUAD  (Camp  Smith,  HI)  —  intended  for  CPX  only;  received 
successfully  aboard  BLR  on  fourth  day  of  CPX  (17  April  2003);  used  for  TES-N  MSEL  events 
for  two  days  until  JSAF-ASSET  transmissions  were  successfully  received  on  BLR  (19  April). 

(2)  JSAF-ASSET  (NWDC  Newport,  RI)  -  last  two  days  of  CPX,  all  of 


FTX. 


(3)  ISR  UUV-CSIM  (NUWC  Newport,  RI)  —  never  successful  going 
direct  to  TNMC  (see  below),  but  were  able  to  email  draft  TACELINT  to  ASSET  operator  in 
Simms  Hall  who  would  ingest  into  ASSET  and  sent  to  TNMC. 
b.  ISSUES/COMMENTS: 

(1)  BLR/C7F  internal  ELINT  flow.  For  the  first  three  days  of  the  CPX, 
no  exercise  ELINT  was  received  by  any  TT03/FBE-K  afloat  players.  This  fact  by  itself  (never 
mind  the  reasons  for  it)  was  difficult  to  identify  because  of  major  ELINT  connectivity  issues 
within  the  lifelines  of  BLR  (e.g.,  bad  connectors,  wiring  missing  between  TRE  and  TES-N)  that 
took  experts  from  ship,  staff,  and  NWDC/SPAWAR  (Meana)  the  better  part  of  ten  days  prior  to 
STARTEX,  and  into  the  first  day  of  CPX,  to  troubleshoot  and  correct. 

(2)  ASSET  via  TNMC.  TNMC  would  not  accept  simulated  ELINT 
injects  from  JSAF-ASSET  at  Newport  until  the  last  two  days  of  CPX  (19  April  2003)  [unable  to 
verify  reason  for  this  delay].  In  the  meantime,  the  Newport  ASSET  operator  coordinated  with 
the  Camp  Smith  JQUAD  operator  to  provide  ELINT  injects  for  the  TES-N  TST  MSELs,  which 
worked  successfully. 

(3)  ISR  UUV  via  TNMC.  The  problem  was  with  pennissions  from 
TNMC,  apparently  because  COMPACFLT  never  forwarded  the  CESR  to  TNMC  FORAC,  and 
because  TNMC  was  comfortable  with  ASSET  (having  worked  with  it  in  many  previous 
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exercises/experiments),  but  knew  nothing  of  ISR  UUV’s  CSIM  —  TNMC  undoubtedly  wanted  to 
avoid  taking  any  risks,  due  to  the  real  world  use  (e.g.,  Gulf  War  II)  of  the  TDDS  broadcast. 

(4)  GALE  and  ESM  Lines-of-Bearing  (LOBs).  One  of  the  specific 
reasons  for  using  the  ISR  UUV  simulation  in  FBE-K  FTX  was  to  see  how  TES-N’s  GALE 
software  would  process  ESM  LOBs  of  the  sort  most  likely  to  be  produced  by  an  ISR  UUV 
platform  —  it  apparently  couldn’t.  Despite  the  presence  of  ELINT  analytic/GALE  operator 
expertise  (both  organic  to  C7F,  and  in  the  person  of  a  Mobile  Training  Team  {MTT} 
ELINT/GALE  trainer),  the  TES-N  GALE  was  unable  to  receive,  process,  and  display 
TACELINT  messages  from  ISR  UUV  that  reported  an  LOB.  These  messages  were  apparently 
being  received  and  processed  by  GCCS-M,  as  a  number  of  LOBs  were  seen  on  the  GCCS-M 
COP  with  the  simulated  ISR  UUVs  as  the  origin  of  the  LOB.  As  a  work-around,  the  NWDC 
Facilitators  had  the  M&S  operators  in  Newport  send  the  TACELINTs  as  very  thin,  elongated 
ellipses  —  so  thin  (semi-minor  axis)  that  they  would  look  like  a  single  line  on  the  display,  with  a 
center  point  around  the  simulated  target  producing  the  emission,  and  a  length  (semi-major  axis) 
twice  the  length  of  the  distance  between  the  ISR  UUV  sensor  and  the  simulated  emitter,  and 
oriented  so  that  it  looked  like  a  line  emanating  from  the  ISR  UUV’s  location  and  passing  through 
and  beyond  the  target. 

5.  COMINT: 

a.  ACCOMPLISHMENTS: 

(1)  CPX.  In  the  CPX,  COMINT  injects  were  to  be  crafted  by  scripters 
from  Kunia  Regional  SIGINT  Operations  Center  (KRSOC)  who  were  resident  in  the  TT03 
JECG  at  Camp  Smith,  HI.  These  injects  would  then  be  sent  via  the  SI  broadcast  to  BLR,  and 
received  by  a  COMINT  analyst  using  a  TES-N  MFWS.  What  actually  happened  was  the 
COMINT  injects  (once  they  got  flowing)  were  received  only  on  SCI  GCCS-M,  as  that  is  the  way 
the  BLR  SCI  architecture  was  configured  (see  ISSUES/COMMENTS  section  below). 

(2)  FTX.  In  the  FTX,  the  intention  was  to  continue  the  participation  of 
KRSOC  scripters,  and  simply  re-use  their  COMINT  injects  (with  slight  modifications  as 
needed).  Unfortunately,  the  KRSOC  scripters  could  not  stay  for  the  FTX,  and  as  a  result  the 
COMINT  injects  during  FTX  boiled  down  to  the  NWDC  Facilitator  (Sweitzer)  crafting  a 
GESNSER-level  COMINT  spot  report  (roughly  based  on  the  gist  of  the  MSEL  injects)  using  MS 
Outlook  on  an  IT-21  machine  in  the  BLR  JIC,  and  emailing  the  report  to  as  the  “initial  tipper”  to 
the  appropriate  MSEL  events. 

b.  ISSUES/COMMENTS: 

(1)  CPX  COMINT  injects.  At  CPX  STARTEX,  the  KRSOC  scripters 
were  just  arriving  at  the  JECG,  and  it  took  several  days  to  get  set  up,  to  work  out  procedures,  and 
to  have  them  provide  enough  detail  for  the  COMINT  injects  to  be  of  use  as  tippers  to  specific 
TST  MSEL  events.  The  COMINT  analyst  at  the  SCI  GCCS-M  would  receive  the  injects  as 
emails,  print  them  off,  and  walk  them  (about  20-25  feet)  over  to  where  the  TST  team  was 
manning  their  TES-N  terminals.  This  only  worked,  without  prompting  from  the  NWDC 
Facilitators,  on  the  last  day  of  the  CPX  (20  April). 

(2)  No  COMINT  analysis  tools  in  TES-N.  The  attempt  to  use  the  SCI 
side  of  TES-N  was  a  total  wash,  as  it  turns  out  TES-N  does  not  have  any  true  COMINT  analysis 
tools  (as  does  SCI  GCCS-M),  other  than  allowing  the  viewing  of  SCI  messages  such  as 
KLIEGLIGHTS  or  TACREPS,  and  the  plotting  of  locational  data  on  a  map  —  both  of  which  SCI 
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GCCS-M  already  does  (and  in  C7F  cryptologists’  view,  does  better).  For  this  reason,  C7F 
cryptologists  (along  with  the  rest  of  the  Navy’s  cryptologic  community  —  at  least  according  to 
the  C7F  Fleet  Cryptologist)  have  chosen  to  not  use  TES-N  for  COMINT  analysis. 

Consequently,  none  of  the  required  connectivity  (other  than  JWICS  Intelink  web-browsing 
access,  and  SCI-level  chat)  for  using  SCI  TES-N  was  not  in  place  for  use  during  TT03/FBE-K. 
While  attempts  were  made  to  effect  this  connectivity  during  TT03/FBE-K,  the  effort  was  seen  by 
NWDC  Facilitators  and  C7F  personnel  as  being  low  priority  compared  to  other  issues  being 
dealt  with  simultaneously  (both  in  TT03/FBE-K  and  in  the  “real  world”),  so  it  never  got  done. 

(3)  TES-N  ISSE  Guard  was  non-functional  on  BLR.  Part  of  the  concept 
of  using  SCI  TES-N  for  the  COMINT  analyst  member  of  the  TST  team  was  to  exercise  use  of 
the  Infonnation  Support  Server  Environment  Guard  (ISSE)  Guard  to  move  appropriate  data  from 
the  SCI  side  of  TES-N  to  the  GENSER  side  of  TES-N  in  support  of  TST  processes. 
Unfortunately,  no  BLR/C7F  personnel,  TES-N  FSRs,  or  JFN  Mobile  Training  Team  (MTT) 
members  knew  anything  about  configuring  or  operating  the  ISSE  Guard. 

C.  TES-N  OUTPUTS. 

1.  Target  nomination  messages  (ATI.ATRs)  to  ADOCS  and  to  TST  Target  Folder 
Server: 

a.  ACCOMPLISHMENTS:  The  objective  was  for  the  TST  nomination  analyst  to 
use  TES-N  to  create  a  target  nomination  message  (in  USMTF  “ATI.ATR”  fonnat),  and  to  send 
that  nomination  message  (via  SMTP)  to  the  ADOCS  server  on  BLR,  and  to  the  TST  Target 
Folder  server  at  NWDC  in  Newport,  RI.  [ADOCS  was  set  up  so  that  it  would  not  only  receive 
the  ATI.ATR  from  TES-N,  but  after  parsing  it  would  turn  around  another  ATI.ATR  to  the  TST 
Target  Folder  server  —  so  that  the  target  folder  for  any  given  TES-N  created  TST  nomination  had 
both  the  ATI.ATR  that  come  directly  from  TES-N,  and  the  ATI.ATR  that  was  “turned  around” 
by  ADOCS].  The  first  successful  nomination  output  by  TES-N  as  part  of  a  TST  MSEL  event 
was  accomplished  on  CPX  day  five  (18  April  2003);  the  process  worked  for  the  last  three  days  of 
CPX  and  the  first  day  of  FTX,  was  inoperative  for  three  days,  and  then  worked  again  for  the  last 
four  days  of  the  FTX. 

b.  ISSUES/COMMENTS: 

(1)  Nomination  creation  and  sending.  It  took  four  days  to  rectify  issues 
with  SMTP  across  the  various  networks  and  systems  (TES-N  LAN,  ship’s  LAN/Exchange 
server,  FBE-K  WAN  and  Exchange  servers,  ADOCS  mail  server)  to  first  get  TES-N’s  ATI.ATR 
messages  to  be  received  by  ADOCS  and  the  TST  Target  Folder  server.  In  the  case  of  the  TST 
Target  Folder  server,  access  was  impossible  for  the  first  three  days  of  CPX  TST  MSEL  events 
due  to  the  FBE  WAN  being  inoperable  until  CPX  day  four  (17  April  2003).  Once  set  up 
properly,  no  problems  were  encountered  until  FTX  day  two  (26  April  2003)  when  the 
nominations  began  getting  “stuck”  in  the  TES-N  outgoing  message  queue,  and  by  the  next  day 
TES-N  would  not  even  allow  the  analyst  creating  the  ATI.ATR  to  save  it  to  the  TES-N  database, 
a  prerequisite  to  sending  the  target  nomination  message  out.  The  cause  was  determined  by  the 
FSRs  to  be  corrupted  files  in  the  TES-N  Cross-INT  filter  database  (e.g.,  log  files  were  over¬ 
filled),  a  problem  that  took  approximately  three  days  to  troubleshoot  and  correct,  during  which 
time  all  target  nominations  were  manually  entered  into  ADOCS  (e.g.,  “yellow-sticky”  transfer 
from  TES-N  analysts  to  Targeting  Officer  sitting  at  ADOCS  workstation  in  BLR  JIC). 
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(2)  Problems  with  parsing/formatting.  Almost  immediately  after  the  first 
successful  ATI.ATR  output  by  TES-N,  ADOCS  users  began  complaining  that  the  TES-N 
analysts  were  not  giving  the  nominated  targets  a  proper  target  identification  (TGTD).  Two  days 
later  (i.e.,  on  the  last  day  of  CPX),  inconsistencies  were  noticed  in  how  the  target  nominations 
were  being  handled  by  ADOCS  and  how  they  were  showing  up  in  the  TST  Target  Folder  server. 
Not  until  late  in  the  evening  of  FTX  day  five  was  controlled  testing  able  to  be  done  by  the 
NWDC  Facilitator  (Sweitzer),  during  which  fault  was  found  in  both  TES-N  and  ADOCS.  Part 
of  the  confusion  was  because  the  TES-N  target  nomination  creation  template  allows  the  analyst 
to  give  the  target  an  identification  (e.g.,  type,  equipment  name,  etc.)  using  either  the  “TST”  or 
the  “TGTD”  lines,  but  not  both.  ADOCS,  on  the  other  hand,  apparently  only  uses  the  “TGTD” 
line  for  target  identification.  For  instance,  when  the  TES-N  ATI.ATR  message  used  the  “TST” 
line,  ADOCS  would  “turn  around”  to  the  TST  Target  Folder  server  an  ATI.ATR  with  no  “TST” 
line  and  a  blank  “TGTD”  line  (e.g.,  “TGTD/-//-//”);  whereas,  if  the  TES-N  message  used  the 
“TGTD”  line,  ADOCS  would  “turn  around”  an  ATI.ATR  with  both  a  “TGTD”  line  (whose  fields 
were  out  of  order  and  truncated  compared  to  the  original  ATI.ATR)  and  at  “TST”  line 
(containing  the  same  fields  as  “TGTD”  line).  ADOCS  also  changed  several  other  fields  of  other 
lines  for  no  known  reason,  most  notably  the  “DTG”  line  and  field  contents. 

2.  Images  related  to  target  nominations  to  PTW  for  aimpoint  refinement: 

a.  ACCOMPLISHMENTS:  The  objective  was  for  the  TST  nomination  analyst  to 
attach  the  image  or  several  images  (e.g.,  video  “chips”  showing  the  TST)  to  the  outgoing  target 
nomination,  and  send  the  nomination  simultaneously  to  three  places: 

(1)  to  ADOCS  to  begin  weapon-target  paring  and  engagement  processes; 

(2)  to  the  TST  Target  Folder  server  to  either  create  a  new  target  folder  or 
update  an  existing  target  folder;  and, 

(3)  to  PTW  to  begin  the  aimpoint  refinement  process.  It  was  known  long 
before  STARTEX,  however,  that  the  version  of  PTW  used  on  BLR  for  TT03/FBE-K  could  not 
receive  and  parse  ATI.ATR  messages  (i.e.,  did  not  have  the  DTMS  software  used  in  MC02/FBE- 
J).  The  work-around  was  supposed  to  be  that  the  PTW  operator  would  open  the  target  folder 
(after  it  had  been  created  in  the  TST  Target  Folder  server  by  step  (2)  above)  and  pull  down  the 
images  from  there. 

b.  ISSUES/COMMENTS: 

(1)  TES-N  does  not  allow  images  to  be  attached  to  outgoing  ATI.ATRs. 
Even  in  TES-N  version  5.0,  analysts  still  cannot  attach  images  to  outgoing  ATI.ATR  messages. 
Consequently,  all  images  captured,  “chipped”  and  saved  (as  NITF)  in  TES-N  had  to  be  manually 
transferred  (FTP)  to  PTW.  The  PTW  operator  would  then  pull  up  the  images  and  conduct 
aimpoint  refinement  (only  sometimes,  due  to  manning  constraints  and  base  image  quality  issues 
—  see  “M&S  FEEDS  INTO  TES-N”  section  above),  and  then  save  the  images  (as  both  JPEG  and 
NITF)  to  a  shared  directory  on  the  BLR  IT-21  LAN. 


3.  Images  related  to  target  nominations  to  TST  Target  Folder  Server: 

a.  ACCOMPLISHMENTS:  The  objective  was  for  the  TST  nomination  analyst  to 
attach  the  image  or  several  images  (e.g.,  video  “chips”  showing  the  TST)  to  the  outgoing  target 
nomination  so  that  the  TST  Target  Folder  server  could  add  the  image(s)  to  the  target  folder  for 
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that  TST.  Because  even  the  new  version  5.0  of  TES-N  software  still  cannot  attach  images  to 
ATI.ATRs,  the  workaround  for  getting  images  into  the  TST  target  folders  was  for  the  NWDC 
Facilitator  (Sweitzer),  and  later  some  of  the  players  (once  the  were  taught)  would  use  MS 
Outlook  on  an  IT-21  machine  to  manually  create  a  one-line  ATI.ATR  email  (using  the  “TNO” 
line  only)  with  the  subject  line  “Target”,  pull  the  image(s)  from  the  shared  directory  and  attach 
to  the  email,  and  send  to  the  TST  Target  Folder  server.  The  server  would  then  parse  the  email, 
and  use  the  “TNO”  to  update  the  correct  target  folder  with  both  the  ATI.ATR  info  and,  more 
importantly,  the  images  themselves. 

b.  ISSUES/COMMENTS: 

(1)  TST  Target  Folder  server  worked  great.  The  NWDC  TST  Target 
Folder  server  application  proved  to  be  a  simple  but  powerful  prototype  that  was  important  to 
both  the  CPX  and  the  FTX  (though  up  until  two  weeks  prior  to  STARTEX  its  role  in  CPX  was 
still  unknown).  Its  importance  became  clear  when,  mid-way  through  FTX,  there  was  one  brief 
period  where  the  parser  script  stopped  working  properly  —  and  while  it  was  rapidly  and  easily  re¬ 
started,  the  level  and  swiftness  of  “protest”  from  the  participants  made  clear  it  had  become  an 
important  factor  for  them.  Despite  so  many  process  artificialities,  the  players  were  able  to  see 
the  value  of  a  common,  web-accessible  repository  for  infonnation  and  images  related  to  any 
given  TST,  thereby  hopefully  preparing  those  aboard  BLR  for  the  program  of  record  target 
folder  application  (Joint  Targeting  Toolbox)  that  was  to  be  installed  later  this  Spring. 

4.  TST  location  output  to  COP  (i.e.,  Manual  Contact  to  GCCS-M)  for  “tracking”  and 
SA: 

a.  ACCOMPLISHMENTS:  The  objective  was  for  the  TST  nomination  analyst  to 
not  only  create  an  ATI.ATR  as  above,  but  to  then  use  TES-N’s  rudimentary  interface  to  GCCS- 
M  to  input  the  target  into  the  COP  as  a  track,  for  the  situational  awareness  of  ALCON,  and  to 
assist  (theoretically)  in  the  “tracking”  of  the  TST  while  waiting  for  it  to  be  engaged. 

b.  ISSUES/COMMENTS: 

(1)  GCCS-M  configuration  on  BLR  was  sub-optimal.  The  GCCS-M 
configuration  on  BLR  had  a  wide  variety  of  serious  issues  (e.g.,  different  software  versions  from 
machine  to  machine),  some  of  which  took  the  entire  event  to  straighten  out.  This  effort  impacted 
the  TES-N  to  GCCS-M  interface  in  that,  even  though 

(2)  TES-N  output  to  GCCS-M  was  inoperative  on  BLR  for  CPX.  Even 
with  the  new  TES-N  version  5.0,  there  was  no  improvement  in  TES-N’s  ability  to  output  to 
GCCS-M  from  what  was  used  in  MC02/FBE-J.  In  fact,  the  capability  did  not  exist  until  the 
NWDC  Facilitators  came  aboard  and  showed  the  C7F  staff  how  the  creation  of  a  “Manual 
Contact”  in  TES-N  at  the  same  location  as  the  nominated  TST  (which  was  already  in  TES-N’s 
Cross-INT  database  and  was  displayable  using  TES-N’s  Integrated  Tactical  Display  [ITD] 
application)  could  then  be  set  up  to  be  sent  periodically  as  a  formatted  message  (OTH-Gold  or 
XCTC)  to  GCCS-M’s  JOTS1.  It  took  the  entire  CPX  to  focus  enough  time  and  energy  to 
troubleshoot  this  interface  and  get  it  working.  It  worked  for  the  first  two  days  of  FTX,  and  then 
suffered  the  same  problem  as  the  TES-N  target  nominations  (i.e.,  nothing  could  be  saved  to  the 
Cross-INT  database)  and  was  never  able  to  be  brought  back  up  —  consequently,  the  GCCS-M 
“Red  database  analyst”  was  never  able  to  become  part  of  the  process  (e.g.,  changing  the  “hard¬ 
wired”  TES-N-assigned  track  name  to  reflect  the  Target  Block  Number  assigned  to  that  TST  by 
TES-N  during  the  target  nomination  creation  process). 
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(3)  BOTTOM  LINE:  the  TES-N  output  to  GCCS-M  only  worked  for  two 
days  at  the  same  rudimentary  and  suboptimal  level  at  which  it  was  working  for  MC02/FBE-J;  for 
the  remainder  of  TT03/FBE-K  it  was  functionally  inoperative. 

5.  U-2  mission  plan  creation  and  output  to  AFSERS-TENCAP: 

a.  ACCOMPLISHMENTS:  Because  the  Air  Force  (specifically  JFACC  Rear  at 
Hickam  AFB)  was  unable  to  create  U-2  mission  plans  for  TT03/FBE-K  (citing  real  world 
commitments  of  their  experts),  and  because  the  JFN  Mobile  Training  Team  members  were 
delayed  coming  aboard  (due  to  early  BLR  sortie  from  Guam  for  typhoon  avoidance),  NWDC 
Facilitator  (Sweitzer)  used  a  well-written  help-tutorial  on-line  in  TES-N’s  EMPS  application  to 
create  a  mission  plan  to  output  to  AFSERS-TENCAP  for  its  use  in  providing  a  simulated  feed  of 
U-2  imagery  and  telemetry  back  to  TES-N.  [Note:  a  U-2  mission  plan,  or  “OP”  in  EMPS 
tenninology,  consists  of  a  navigation  plan  and  a  collection  plan  built  using  a  specific  set  of 
collection  requirements  for  a  specific  sensor  type,  associated  with  a  specific  aircraft  tail  number, 
flying  a  specific  track,  downlinking  to  a  specific  ground  station]. 

b.  ISSUES/COMMENTS: 

( 1)  EMPS  uses  different  maps  than  ITD.  One  example  of  the 
“immaturity”  of  the  internal  integration  between  many  of  TES-N’s  applications  is  the  fact  that 
EMPS  (Enhanced  Mission  Planning  System)  uses  completely  different  maps  than  does  ITD 
(Integrated  Tactical  Display).  Not  only  does  it  load  the  maps  from  a  different  set  of  files,  but  the 
user  interface  (e.g.,  zoom,  pan,  etc.)  is  completely  different  (and  very  cumbersome).  This  made 
the  process  of  mission  plan  creation  even  more  difficult  to  leam,  and  was  just  another  element 
that  added  to  the  delay  in  getting  the  U-2  simulation  to  work  properly. 

(2)  AFSERS-TENCAP  can  only  reliably  simulate  ASARS  sensors. 
AFSERS-TENCAP  could  not  ingest  the  initial  U-2  mission  plans  built  for  the  EO  sensor 
packages  (SYERS  and  SYERS  2).  The  AFSERS-TENCAP  technician  on  board  BLR  said  that, 
as  far  as  he  knew,  AFSERS-TENCAP  simulation  only  worked  with  the  SAR  sensors  packages 
(ASARS,  ASARS  2,  and  ASARS  2A).  Finally,  on  the  second  to  last  day  of  CPX  (19  April  2003, 
Patriots  Day  in  Massachusetts),  a  U-2  ASARS  2  mission  plan  was  successfully  built  in  EMPS, 
output  to  and  ingested  by  AFSERS-TENCAP,  and  “played  back”  into  TES-N,  with  both 
telemetry  and  images  (albeit  EO  and  not  SAR)  being  received  and  displayed  properly  by  TES-N. 

6.  DIOP  of  U-2  imagery  and  telemetry  to  ISRM  (CPX)  and  ESSEX  RTC  (FTX) 

a.  ACCOMPLISHMENTS:  The  objective  in  CPX  was  to  have  the  U-2 
simulation  coming  into  TES-N  from  AFSERS-TENCAP  “turned  around”  to  the  ISRM 
(Intelligence  Surveillance  Reconnaissance  Manager  —  which  is  in  reality  a  TES  RTC  just  re¬ 
named  by  USAF)  at  Hickam  AFB  using  the  TES-N  Data  Input/Output  Port  (DIOP).  DIOP  is  a 
proprietary  means  of  efficiently  transferring  the  large  amounts  of  data  between  “TES  family” 
systems  such  as  TES,  TES-N,  RTCs,  and  ISRM  (as  the  TES-N  training  manual  says,  “DIOP 
allows  real-time  screening  and  exploitation  of  direct  downlink  tactical  imagery  by  users  without 
direct  sensor  access.”).  Doing  the  same  to  the  TES-N  RTC  aboard  USS  ESSEX  (ESX)  during 
FTX  had  been  discussed  early  in  FBE  planning,  but  had  been  considered  cancelled  due  to  real- 
world  events  —  in  the  end,  ESX  turned  out  to  be  available,  and  so  DIOP  was  attempted  (although 
somewhat  “ex-scenario”  as  ESX  had  no  other  means  of  participation  in  the  TST  MSEL  events). 
The  DIOP  connectivity  between  BLR,  ISRM,  and  ESX  RTC  tested  successfully  before  CPX 
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STARTEX  using  recorded  mission  tapes  and  demo  files  built  from  actual  U-2  missions 
specifically  to  demonstrate  and  train  the  DIOP  capability  when  no  live  U-2  was  airborne  and 
downlinking. 

b.  ISSUES/COMMENTS:  AFSERS-TENCAP  simulation  stream  cannot  be 
“DIOP’d”.  On  the  last  day  of  the  CPX  (20  April  2003),  after  a  day  of  successful  receipt  into 
TES-N  of  simulated  U-2  imagery  and  telemetry  produced  by  AFSERS-TENCAP,  the  NWDC 
Facilitators  asked  the  TES-N  FSRs  to  attempt  to  DIOP  the  sim-U-2  feeds  to  ISRM  at  Hickam. 
This  revealed  that,  because  AFSERS-TENCAP  uses  different  processes  (FTP  for  imagery  and 
UDP  for  telemetry)  to  provide  the  inputs  to  TES-N  than  a  live  U-2  (which  would  be  sending  it 
through  the  CDL-N  and  CIP),  the  AFSERS-TENCAP  feeds  could  not  be  turned  around  using 
DIOP  [unable  to  get  further  specifics  as  to  why,  but  suspect  it  has  to  do  with  the  custom  script 
that  had  to  be  installed  and  run  to  receive  AFSERS-TENCAP  simulation  in  the  first  place  —  see 
“M&S  FEEDS  TO  TES-N”  section  above]. 

7.  File  transfer  to  ISRM  (CPX)  and  ESSEX  RTC  /  RTC  Lites  (FTX) 

a.  ACCOMPLISHMENTS:  Because  “DIOP”  is  only  for  the  transfer  of  U-2 
imagery  that  is  being  (or  has  just  been)  directly  downlinked,  other  file  types  must  be  exchanged 
between  TES-N  and  remotes  like  ISRM  and  RTCs  using  standard  means  such  as  FTP  and 
SMTP.  During  FTX  only,  three  RTC  Lites  were  employed,  one  aboard  the  vSSN  (virtual 
submarine  simulator  at  NUWC,  Newport,  RI),  one  aboard  the  E2XV  (Experimental  Hawkeye- 
2003  surrogate  van  in  the  NWDC  parking  lot  in  Newport,  RI),  and  one  aboard  the  virtual  DDX 
(at  NSWC  Dahlgren,  VA). 

b.  ISSUES/COMMENTS: 

(1)  FTP  and  SMTP  worked  great.  With  the  exception  of  the  very  first  day 
of  CPX  when  the  ISRM  at  Hickam  was  not  yet  manned,  all  attempts  to  transfer  files  between 
TES-N  and  ISRM  (in  CPX)  and  ESX  RTC  (in  FTX)  by  FTP  or  SMTP  were  successful. 

(2)  RTC  Lites  worked  —  eventually.  The  RTC  Lite  at  NUWC  had  been 
used  in  previous  FBEs,  and  was  fairly  easy  to  get  up  and  going.  Configuring  the  other  two  RTC 
Lites  was  a  difficult  task  to  which  little  effort  could  be  committed  (due  to  their  low  priority 
relative  to  other  issues  that  were  consuming  the  FSRs’  attentions).  The  vDDX  RTC  Lite  began 
receiving  exercise  data  on  FTX  day  four  (28  April  2003),  and  the  E2XV  RTC  Lite  on  FTX  day 
six  (30  April  2003).  The  actual  utility  of  these  RTC  Lites  to  those  “virtual  shooter”  nodes 
remains  indeterminate. 

8.  Cross-INT  replication  from  TES-N  to  ISRM  (CPX)  and  ESSEX  RTC  (FTX) 

a.  ACCOMPLISHMENTS:  Replication  of  TES-N’s  Cross-INT  database  was 
attempted  to  both  ISRM  (CPX)  and  the  ESX  RTC  (FTX),  but  with  very  limited  success. 

b.  ISSUES/COMMENTS: 

(1)  During  CPX,  Cross-INT  was  not  replicated  to  ISRM.  Due  to  higher 
priority  issues,  replication  between  BLR  TES-N  and  the  ISRM  at  Hickam  (which  is  for  all 
practical  purposes  a  TES  RTC)  was  only  attempted  CPX  day  six,  but  was  unsuccessful  due  to 
instability  problems  with  ISRM. 

(2)  During  FTX,  Cross-INT  was  replicated  to  ESX  RTC  —  worked  too 
well!  Starting  on  FTX  day  two  (not  attempted  on  FTX  day  one),  Cross-INT  replication  with 
ESX  RTC  was  successful  —  for  two  days.  In  fact,  according  the  preliminary  evaluation  by  the 
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TES-N  FSRs  on  BLR,  the  large  amounts  of  data  “pulled”  [NFI]  by  ESX  RTC  was  probably  the 
major  contributor  to  the  corruption  of  TES-N’s  Cross-INT  filter  database  files  that  caused  TES- 
N  to  be  NMC  (non-mission  capable)  for  TST  support  during  FTX  days  three  and  four.  In  order 
to  assist  with  troubleshooting  and  ensure  TES-N  stability  for  the  reminder  of  FTX,  no  further 
replication  with  ESX  RTC  was  attempted.  [Instead,  TES-N  analysts  from  ESSEX  flew  over  to 
BLR  for  the  last  two  days  of  FTX  so  they  could  take  advantage  of  the  presence  of  the  JFN  MTT 
and  the  M&S  flows  into  TES-N]. 

(3)  Target  Nominations  created  in  TES-N  are  not  replicated  to  ISRM  / 
RTC.  This  means  Target  Nominations  created  by  TES-N  have  to  be  passed  by  some  other 
means  to  ISRM  /  RTC.  During  CPX,  target  nominations  were  passed  to  JFACC  Rear  (Hickam 
AFB,  HI)  via  chat;  during  FTX,  target  nominations  were  not  passed  at  all  the  ESX  RTC,  as  they 
were  not  “players”  per  se  in  the  TST  MSEL  events. 

D.  OTHER. 

1.  GCCS-M  COP  Tracks  into  TES-N  ITD. 

a.  ACCOMPLISHMENTS:  In  addition  to  TES-N’s  rudimentary  capability  to 
send  “Manual  Contacts”  to  GCCS-M,  COP  tracks  can  also  be  sent  from  GCCS-M  to  TES-N. 

The  objective  of  attempting  to  do  so  in  TT03/FBE-K  was  to  provide  a  richer  context  of  contacts, 
tracks,  Blue  ISR  asset  locations,  etc.  in  TES-N  for  the  analysts  trying  to  “find  and  fix”  TSTs. 

b.  ISSUES/COMMENTS: 

(1)  TES-N  receipt  of  GCCS-M  tracks  had  problems.  During  CPX, 
NWDC  Facilitators  were  only  able  to  make  occasional,  hasty  checks  (due  to  higher  priority 
issues)  on  the  status  of  GCCS-M  tracks  being  received  in  TES-N.  During  each  check,  TES-N’s 
incoming  “Message  and  Data  Log”  showed  a  good  number  of  incoming  tracks  from  GCCS-M, 
but  those  tracks  did  not  appear  to  be  parsing  into  the  TES-N  ITD  [unable  to  compare  the  number 
of  tracks  sent  by  GCCS-M  to  the  number  of  those  tracks  successfully  received  by  TES-N],  On 
the  first  day  of  the  FTX,  it  was  discovered  that  no  GCCS-M  tracks  had  been  received  in  TES-N 
for  the  several  day  transition  period  between  CPX  and  FTX.  After  a  few  hours  the  problem  was 
rectified,  and  the  tracks  flowed  as  before  for  a  day  (but  unable  to  be  displayed  on  ITD),  but  then 
TES-N  experienced  the  Cross-INT  filter  database  file  corruption  problem  (see  above).  After  one 
more  “down  day,”  receipt  of  tracks  was  again  restored,  but  still  no  ITD  display  capability. 
Finally,  with  four  days  left  in  the  FTX,  the  GCCS-M  tracks  coming  into  TES-N  were  able  to  be 
brought  up  on  the  ITD;  however,  it  was  discovered  that  TES-N  ITD  did  not  display  any  track 
labels  (see  issue  (2)  directly  following). 

(2)  TES-N  ITD  displayed  GCCS-M  track  locations,  but  no  labels.  When 
GCCS-M  tracks  were  brought  up  in  TES-N’s  ITD,  the  tracks  appeared  in  their  proper  locations 
(albeit  using  TES-N  symbology  which  is  based  on  MIL-STD-2525,  and  not  with  GCCS-M 
symbololgy)  but  the  symbols  do  not  have  any  labels  associated  with  them  (e.g.,  no  track  names), 
making  them  all  but  functionally  useless  to  the  TST  team. 

2.  M&S  simulated  ISR  asset  display  in  GCCS-M  COP. 

a.  ACCOMPLISHMENTS:  By  the  end  of  FTX,  all  of  the  simulated  Blue  ISR 
assets  active  in  M&S  were  simultaneously  displayed  on  BLR’s  GCCS-M  COP  with  appropriate 
labels  (e.g.,  two  ISR  UUVs,  two  Predator  UAVs,  one  U-2). 


168 


b.  ISSUES/COMMENTS:  This  was  the  first  time  known  to  either  NWDC 
Facilitator  on  BLR  that  this  has  happened  in  an  FBE.  The  key  enablers  were  very  closely 
coordinated  troubleshooting  between  the  NWDC  Facilitator  (Meana),  the  FBE-K  ATO  builder 
(Specht),  the  M&S  Director  (Dial),  and  the  GCCS-M  Tech  on  BLR  (DeMarco). 

3.  Live  P-3C  video  downlink  via  CDL-N  into  TES-N  [ex-scenario]. 

a.  ACCOMPLISHMENTS:  During  the  two  weeks  prior  to  TT03/FBE-K  (on  5 
April  2003),  a  VPU  aircraft  was  able  to  spend  the  better  part  of  a  day  within  line-of-sight  of 
BLR,  specifically  to  test  the  live  downlink  of  EO/IR  video  from  the  aircraft’s  new  TCDL  into 
TES-N  using  the  ship’s  CDL-N  antenna  and  CVIU  (no  NIU).  With  assistance  from  NWDC 
Facilitators  (Meana  in  particular),  and  with  remote  contractor  support  by  phone,  sailors  from 
BLR  ships  company  and  C7F  staff  were  able  to  employ  the  lessons  learned  from  four  previous 
unsuccessful  attempts  to  make  this  event  successful. 

b.  ISSUES/COMMENTS:  While  this  event  was  ex-scenario  with  regards  to 
TT03/FBE-K  it  did  several  things  that  positively  impacted  TT03/FBE-K,  including: 

(1)  testing  the  internal  TES-N  video  path  from  video  switch  to  MFWS; 

(2)  familiarizing  TES-N  analysts  with  the  TES-N  video  screening  and 
frame  capture  tools  (as  well  as  the  quality  of  live  video,  with  which  they  could  contrast 
simulated  video); 

(3)  helping  to  solidify  the  NWDC  Facilitators  as  “part  of  the  team”. 

Lessons  Learned 

A.  “What  would  you  have  done  differently  with  20/20  hindsight?"  From  the  technical 
perspective,  almost  nothing  —  almost  all  “lessons  TO  BE  learned”  are  in  the  areas  of  FBE 
conduct,  Fleet  “ownership”  and  involvement,  etc. 

B.  “What  did  we  learn  by  employing  this  technology?” 

1 .  Learned  once  again  that  TES-N  is  a  complex  and  developmentally  immature  system 
whose  strength/weakness  are  directly  related  to  the  strengths/weaknesses  of  its  interfaces  with 
communications,  with  other  JFN  systems,  and  with  ADOCS. 

2.  Learned  once  again  that  getting  TES-N  and  the  rest  of  the  JFN  equipment  and  its 
many  intricate  interfaces  to  really  “work”  (fully  mission  capable)  requires  the  regular  (daily?) 
attention  of  a  wide  range  of  cooperating  technicians  and  system  operators,  both  on  board  and  off 
board,  using  scripted  scenarios  (if  not  live  downlink  events)  to  force  issues  to  surface  that  would 
never  appear  in  mere  system  demonstrations  or  static  testing. 

C.  “What  did  we  learn  from  the  issues  that  were  encountered?”  The  answer  to  this  will  not 
be  truly  known  until  the  next  such  experimentation  event  involving  TES-N  /  JFN. 

Recommendations 

A.  Continue  to  improve  quality  of  M&S  video  and  imagery  (e.g.,  1 -meter  base),  and  platform  / 
sensor  /  feed  characteristics  (particularly  simulation  ofU-2  products). 
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B.  Thoroughly  test  TES-N  to  ADOCS  target  nomination  interface  prior  to  event  STARTEX, 
including  a  close  examination  of  how  individual  data  fields  are  handled  through  the  whole 
process. 


C.  Continue  attempts  to  incorporate  program-of-record  digital  target  folder  solution  (e.g.,  Joint 
Targeting  Toolbox,  based  on  MIDB)  into  future  ISR  /  TST  experimentation  events. 

D.  Clarify  division  of  labor  (and  increase  frequency  of  joint  planning  sessions)  between: 

-  Functional  leads 

-  IKA  team 

-  Technical  team 

E.  Assign  COP  ownership  and  explicitly  state  roles  and  responsibilities  (of  above  three,  plus 
players) 

F.  Document  Control  (a  la  “TEP”) 

-  publish  schedule  (“spirals”)  for  document  inputs 

-  larger  issue  than  just  tech  team  (should  be  FBE-wide  —  IKA  lead?) 

G.  Produce  “Functional  Flow  Diagrams”  (FFDs?)  before  technical-level  OSDs 
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Appendix  D  FBE-K  SEA-STRIKE  OBSERVATIONS:  ISR  AND  JFN 

This  Appendix  was  provided  by  Wayne  "Doc"  Sweitzer  of  Titan  Corporation 


1 .  What  follows  are  observations  of  the  FBE-K  ISR  Planner  made  during  the  planning  and 
execution  of  the  Sea  Strike  portion  of  TT03/FBE-K. 

2.  DISCLAIMER:  This  document  may  appear  to  “list”  toward  negative,  as  it  is  meant  to  be  the 
author’s  frank  professional  opinions  and  recommendations  as  to  where  future  FBEs  might  be 
improved,  and  not  a  list  of  accomplishments.  These  observations  are  based  on  direct,  personal 
experience  in  FBE-K,  and  in  numerous  previous  FBEs.  Nothing  herein  is  intended  to  suggest 
fault  or  assign  blame.  The  observations  are  strictly  those  of  the  author,  and  should  not  be 
construed  as  the  official  position,  in  whole  or  in  part,  of  the  Navy  Warfare  Development 
Command  or  Titan  Corporation. 


TABLE  OF  CONTENTS 
Section  1:  BACKGROUND 

Section  2:  FBE  PLANNING,  ORGANIZATION,  AND  EXECUTION  OBSERVATIONS 

Section  3:  FBE  TECHNICAL  AND  SYSTEMS  OBSERVATIONS 

Attachment  A:  CPX  Constraints 

Attachment  B:  ISR  UUV  Functional  Flow  Diagrams 

Attachment  C:  TES-N  Status  Board 

Attachment  D:  Technical  AAR  Paper 

SECTION  1:  BACKGROUND. 

1.1  Fleet  Battle  Experiment  -  Kilo  (FBE-K)  was  conducted  during  April-May  2003  in  concert 
with  Exercise  Tandem  Thrust  2003  (TT03).  The  Officer  Conducting  the  Exercise  (OCE)  was 
Commander,  United  States  Seventh  Fleet  (C7F),  with  Navy  Warfare  Development  Command 
(NWDC)  as  the  primary  organization  coordinating  FBE-K,  and  the  Joint  Warfighting  Center 
(JWFC)  as  the  primary  organization  coordinating  TT03. 

1.2  TT03/FBE-K  took  place  in  two  major  phases:  a  Command  Post  Exercise  (CPX),  followed 
by  a  Field  Training  Exercise  (FTX). 

1.2.1  During  CPX,  the  C7F  Staff  was  being  evaluated  by  JWFC  for  its  ability  to  perfonn 
the  role  of  an  afloat  Commander,  Joint  Task  Force  (CJTF).  FBE-K  Sea  Strike  ISR/JFN  play  was 
limited  to  connectivity  and  interface  testing,  and  basic  Time  Sensitive  Targeting  (TST)  process 
walk-throughs  with  essentially  one  full-time  C7F  Staff  member. 

1.2.2  During  FTX,  NWDC  (the  Sea  Strike  team  in  particular)  was  tasked  to  help  C7F 
conduct  basic  Time  Sensitive  Targeting  (TST)  processes  using  the  Joint  Fires  Network  (JFN) 
and  the  Army  Deep  Operations  Coordination  System  (ADOCS). 


172 


1.3  During  FBE-K,  the  Joint  Fires  Network  (JFN)  was  considered  by  NWDC  to  be  comprised  of 
three  major  subsystems: 

1.3.1  Tactical  Exploitation  System  -  Navy  (TES-N),  with  applications  /  subsystems 
including  (but  not  limited  to): 

-  Geographic  Area  Limitation  Environment  (GALE); 

-  Enhanced  Mission  Planning  System  (EMPS); 

-  Integrated  Tactical  Display  (ITD); 

-  Remote  Terminal  Capability  (RTC); 

-  Remote  Terminal  Capability  -  Lite  (RTC-Lite). 

1.3.2  Global  Command  and  Control  System  -  Maritime  (GCCS-M); 

1.3.3  Joint  Service  Imagery  Processing  System  -  Navy  (JSIPS-N),  with  applications  / 
subsystems  including  (but  not  limited  to): 

-  Precision  Targeting  Workstation  (PTW); 

-  Image  Product  Library  (IPL); 

-  Joint  Concentrator  Architecture  (JCA). 

1.4  FBE-K  events  involving  Sea  Strike  ISR  and  JFN  were  primarily  conducted  aboard  USS 
BLUE  RIDGE  (LCC-19)  at  sea  off  the  Northern  Mariana  Islands  (including  Guam,  Rota,  Tinian, 
Saipan).  Other  involved  nodes  included:  the  Modeling  and  Simulation  (M&S)  laboratory  at 
NWDC  in  Newport,  RI,  with  a  virtual  E2X  (E2XV)  van  parked  just  outside;  the  virtual  SSN  and 
ISR  Unmanned  Underwater  Vehicle  (ISR  UUV)  M&S  at  the  Naval  Undersea  Warfare  Command 
(NUWC),  Newport,  RI;  the  virtual  DDX  (vDDX)  M&S  at  Dahlgren,  VA;  a  virtual  ANZAC  ship 
at  Fern  Hill,  Australia;  a  JFACC  Rear  (CPX  only)  at  Hickam  AFB,  HI;  and  USS  ESSEX  (LHD- 
2). 


SECTION  2:  FEE  PLANNING,  ORGANIZA  TION,  AND  EXECUTION  OBSER I rA TIONS. 

2.1  Continuity  Between  Concept  Development  and  Experiment  Implementation. 

Observation:  A  lack  of  continuity  existed  between  the  development  of  FBE-K 
concepts/initiatives  involving  ISR/JFN,  and  the  actual  FBE-K  planning/implementation.  Among 
other  things,  this  discontinuity  hampered  the  development  of  meaningful  analytic  questions,  and 
the  experimental  techniques  to  help  answer  those  questions. 

Discussion:  By  the  time  the  FBE-K  ISR  Planner  was  brought  aboard,  there  was  no  one 
available  who  could  articulate  the  original  thinking  behind  the  general  concepts  and  initiatives 
involving  ISR  and  JFN  that  had  been  dictated  for  use  during  FBE-K  (e.g.:  “Pervasive 
sensing... from  large  numbers  of  heterogeneous,  widely  distributed  sensors”;  “Dynamic 
management  of  a  tiered  UAV  architecture”;  etc.).  And  because  the  FBE-K  ISR  Planner  had  not 
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been  part  of  the  original  concept  and  initiative  development  process,  the  planning  and 
implementation  of  an  experiment  (or  more  accurately,  a  component  of  a  larger  experiment 
inherently  rife  with  its  own  constraints  —  see  Attachment  A)  that  would  meaningfully  advance 
those  concepts  as  originally  intended  was  for  all  practical  purposes  impossible.  Development  of 
“analysis  questions”  was  particularly  problematic,  as  the  thinkers  who  came  up  with  the  concepts 
and  initiatives  were  not  there  to  help  define  the  details  of  what  it  was  they  were  intending  to 
subject  to  experimentation. 

Recommendation:  Those  involved  in  the  development  of  experimental  concepts  and 
initiatives  must  remain  fully  engaged  throughout  the  FBE  planning  process,  if  not  also  during  the 
execution  and  after-action  analysis,  to  ensure  the  FBE  is  properly  focused  on  addressing  the 
original  intent  of  those  concepts  and  initiatives. 

2.2  Staff  Participation;  Fleet  Training  vs.  Experimentation. 

Observation:  From  the  ISR  perspective,  FBE-K  degenerated  almost  completely  into  a 
JFN  systems  training  event,  largely  because  participation  by  C7F  Staff  and  Fleet  forces  in  the 
planning,  preparation,  and  execution  was  constrained  to  such  an  extent  as  to  preclude  meaningful 
ISR  and  JFN-related  experimentation. 

Discussion:  Fleet  Battle  Experiments  have  been  wedded  to  Numbered  Fleet  participation 
from  their  inception,  sometimes  more  successfully  than  at  other  times.  FBE-K  was  clearly  one 
of  the  “other  times”,  at  least  in  the  areas  of  ISR  and  JFN.  A  major  reason  for  this  was  the  limited 
C7F  Staff  and  Fleet  participation  evident  during  all  of  the  major  FBE  planning  conferences  (and 
most  TT03  planning  meetings  as  well),  where  only  one  intelligence  planner  and  no  operations 
planners  were  available  to  participate  in  ISR  and  JFN-related  working  groups. 

The  lack  of  participation  by  Staff  and  Fleet  operations  personnel  (N3)  was  particularly 
detrimental  as,  without  operations,  the  intelligence  (N2)  portions  of  ISR  and  JFN  are  all  but 
meaningless  (i.e.,  the  proverbial  “self-licking  ice  cream  cone”).  The  limits  of  C7F  staff 
participation  were  most  obvious  during  FBE-K  execution  when  the  only  non-N2  C7F  staff 
“players”  in  ISR  and  JFN-related  events  were  the  civilian  Science  Advisor  and  two  Navy 
Lieutenants  (one  of  whom  was  for  all  practical  purposes  available  only  part-time).  Certainly  the 
travel  distances  and  time  zones  separating  NWDC  planners  and  C7F  Staff  exacerbated  the 
difficulties  during  planning,  as  did  concurrent  C7F  staff  requirements  to  plan  for  both  upcoming 
exercises  and  “real  world”  contingencies.  While  the  constraints  were  obvious  and  largely 
understandable,  the  fact  remains  that  the  limited  C7F  staff  participation  precluded  any 
meaningful  ISR  and  JFN-related  experimentation  during  FBE-K. 

In  fact,  the  only  thing  in  the  ISR/JFN  initiative  that  was  truly  “experimental”  was  the 
inclusion  of  the  ISR  UUV  simulation  in  the  FTX  MSEL  events.  The  employment  of  the  two 
simulated  ISR  UUVs  from  the  vSSN  at  NUWC  forced  an  initial  level  of  interaction  between  the 
ASW  and  Sea  Strike  initiatives,  and  more  importantly  exposed  some  key  Fleet  players  to  this 
emerging  technology. 

Other  than  the  ISR  UUV  experimentation,  the  event  degenerated  into  what  amounted  to 
an  extended  JFN  training  opportunity  for  junior  C7F  N2  personnel  (Navy  Lieutenant  and  below). 
The  training  was  conducted  aboard  USS  BLUE  RIDGE  (LCC-19)  by  two  “Facilitators” 
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supporting  NWDC  (specifically,  a  SPAWAR  civilian  and  this  author),  backed  by  an  extensive 
and  expensive  infrastructure  of  technical,  modeling  and  simulation,  and  experiment  control 
personnel  and  systems. 

A  JFN  Mobile  Training  Team  (MTT)  was  supposed  to  be  available  to  help  with  TES-N 
training  during  the  FBE,  but  they  did  not  make  it  aboard  until  FTX.  Once  aboard,  they  did 
provide  useful  assistance,  but  by  then  most  of  the  TES-N  operators  were  proficient  enough  to  not 
require  further  assistance  to  accomplish  what  was  required  during  this  FBE. 

While  the  event  was  no  doubt  helpful  to  C7F,  and  even  in  certain  ways  to  NWDC,  it  is 
highly  questionable  as  to  whether  Fleet  training  is  an  appropriate  role  for  NWDC,  never  mind 
consideration  of  the  return  on  investment  made. 

Recommendation:  Ensure  ISR  and  JFN  related  experimentation  involving  a  Numbered 
Fleet  has  full  buy-in  and  participation  of  that  Numbered  Fleet  staff,  particularly  the  operations 
(N3)  staff.  Be  prepared  to  postpone  or  cancel  experimentation  events  that  are  dependent  on 
Numbered  Fleet  staff  participation  as  soon  as  it  becomes  obvious  that  the  bulk  of  that  staffs 
focus  will  and  should  be  elsewhere  other  than  on  experimentation.  And  focus  experiments  on 
experimentation,  and  not  on  Fleet  training  /  exercises. 

2.3  NWDC  Division  of  Labor  and  FBE  “Supporting  Services”. 

Observation:  FBE-K  experienced  some  of  the  same  difficulties  with  intra-NWDC 
organizational  challenges  and  “division  of  labor”  issues  as  past  FBEs.  While  these  were 
decidedly  not  “showstoppers”  in  FBE-K,  future  FBE  planning  and  execution  could  be 
significantly  enhanced  by  their  rectification. 

Discussion:  The  FBE  planning  and  execution  tasks  of  the  Functional  Leads,  the  IKA 
Team,  and  the  Technical  Team  each  have  significant  overlaps  that  need  to  be  more  clearly 
addressed  and  delineated.  While  personal  cooperation  and  teamwork  ultimately  “win  the  day” 
and  make  things  work  in  the  end,  the  road  to  getting  there  could  stand  some  smoothing  and 
straightening  in  a  number  of  areas. 

One  of  the  more  difficult  FBE  organizational  challenges  is  the  fact  that  the  Technical 
Team  does  not  work  directly  for  the  Maritime  Battle  Center,  and  so  is  only  nominally  under  the 
control  of  the  FBE  Director.  This  naturally  leads  to  occasional  difficulties  in  areas  such  as: 
prioritization  of  resources  such  as  technical  expertise  and  finances;  “taskings”  from  the 
Technical  Team  (e.g.,  to  cover  meetings,  to  provide  documentation  by  certain  deadlines)  that  can 
be  in  conflict  with  where  the  Functional  Leads  are  headed  when;  and  other  challenges  that 
sometimes  leave  the  impression  that  the  technical  “tail”  is  wagging  the  functional  “dog”  (and  to 
be  fair,  often  times  the  “tail”  if  forced  to  do  so,  because  the  functional  “dogs”  are  not  fully 
prepared  to  provide  requirements  in  the  detail  needed  on  the  technical  side  to  make  architectural 
and  resource  decisions  required  by  fast-approaching  deadlines/“lead  times”). 

A  second  challenge  is  the  fact  that  IKA  is  viewed  as  a  separate  FBE  functional  initiative, 
akin  to  ISR/Fires,  ASW,  AADC,  10,  etc.,  when  in  fact  a  great  deal  of  what  IKA  should  be 
involved  in  during  FBEs  is  the  information/knowledge  management  “layer”  between  the 
functional  initiatives  and  the  Technical  Team’s  network  services.  It  would  be  helpful  in  future 
FBEs  to  make  a  clear  distinction  between  IKA  functional  initiatives,  and  the  “I/KM  services” 
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(e.g.,  websites,  collaboration  tools,  document  control,  etc.)  supporting  the  other  functional 
initiatives  —  and  more  importantly,  who  is  responsible  to  whom  for  what. 

Similarly,  there  are  other  FBE  “supporting  services”  that  too  often  get  overlooked  and/or 
taken  for  granted  as  “going  to  be  there”  (e.g.,  COP,  intelligence/ISR,  OPFOR,  maps  and  charts, 
etc.),  and  as  a  result  sometimes  get  less  attention  than  needed,  or  sometimes  fall  through  the 
cracks  entirely.  For  instance,  who  is  responsible  (between  Functional  Leads,  IKA  Team,  and 
Technical  Team)  for  obtaining  the  correct  maps  and  charts  (softcopy  and  otherwise)  and 
ensuring  distribution  to,  and  installation  for,  all  who  need  them?  Who  is  responsible  for  what 
aspects  (e.g.,  obtaining,  installing,  maintaining)  of  underlying  databases  such  as  DPPDB  and 
MIDB?  Who  is  the  FBE  Lead  responsible  for  “OPFOR”  and  Red  Cell? 

Fortunately,  because  FBE-K  was  dramatically  reduced  from  its  original  scope,  many  of 
these  issues  never  reached  their  “full  potential”  as  FBE  challenges  (although  some  still  did). 
Without  early  clarification  of  these  roles  and  responsibilities,  future  FBEs  could  be  much  more 
significantly  impacted. 

Recommendation:  Provide  greater  clarity  on  intra-NWDC  “division  of  labor”  for  all  the 
various  aspects  of  FBE  planning  and  execution.  Explicitly  identify  “supporting  services”  (such 
as  information/knowledge  management  and  COP/database  maintenance)  that  are  above  the 
strictly  technical  level,  but  are  distinct  from  any  “supported”  functional/experimental  initiatives. 
Assign  appropriate  roles,  responsibilities,  and  resources  to  address  each  of  these  services. 

2.4  Document  Control. 

Observation:  Like  most  previous  FBEs,  FBE-K  suffered  from  a  lack  of  document  control 
for  most  of  the  key  coordinating  documents. 

Discussion:  FBE  planning  (and  sometimes  execution)  is  too  often  hampered  by  a  lack  of 
“command  and  control”  over  key  planning  and  coordination  documents.  These  documents 
include  (but  are  not  limited  to): 

-  the  “official”  FBE  overview  brief; 

-  manning  spreadsheet; 

-  master  SOE  /  MSEL  list; 

-  participating  live  forces  list; 

-  orders  of  battle  (blue,  red,  white),  both  simulated  and  live; 

-  operational  sequence  diagrams  (OSDs); 

-  the  Conolidated  Exercise  Support  Request  (CESR). 

FBEs  by  their  nature  involve  personnel  located  all  over  the  country,  and  sometimes 
literally  around  the  globe,  placing  even  greater  importance  on  the  need  to  keep  all  planners 
working  from  the  same  “sheets  of  music”  (to  adapt  the  well-worn  analogy).  Symptoms  caused 
by  loose  document  control  that  have  been  experienced  first  hand  (and  otherwise)  in  past  FBEs 
have  included,  but  are  not  limited  to: 

-  confusion  resulting  from  failure  to  identify  key  FBE  documents,  and  assign 

explicit  “ownership”  responsibility  for  each  document; 

-  lack  of  participation  by  intended  document  contributors,  often  due  to  the 

document  “owner”  not  making  the  roles  &  responsibilities  of  contributors  clear; 
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-  duplication  of  effort  (e.g.,  two  or  three  authors  producing  essentially  the  same 
documentation  concurrently); 

-  man-hours  wasted  editing  old  versions  of  documents,  only  to  find  out  later  the 
edits  are  O.B.E.; 

-  limited  accessibility  to  the  “most  current  version”  of  key  documents,  and/or 
limited  visibility  into  what  the  “most  current  version  number”  is  at  any  given 
time. 

The  major  notable  exception  during  FBE-K  (and  FBE-J  before  it)  was  the  Technical 
Engineering  Plan  (TEP),  the  “C2”  of  which  should  be  used  as  a  model  for  future  control  of  all 
major  FBE  documents,  with  perhaps  some  improvement  in  visibility  into  the  “most  current 
version  number”  (for  example,  via  a  listing  of  “the  latest”  document  version  numbers  posted  on  a 
well-maintained  web  site). 

Recommendation:  Early  in  the  FBE  planning  stages,  identify  key  coordinating 
documents  (and  their  owners),  and  implement  an  FBE-wide  common  methodology  for  the 
cooperative  production,  review,  maintenance  and  accessibility  of  those  documents  —  while  at  the 
same  time  keeping  this  “FBE  document  control”  methodology  /  system  as  accessible,  flexible, 
and  non-burdensome  as  possible. 

2.5  Live  Forces,  ISR  Assets,  OPFOR,  Emitters,  and  Fires. 

Observation:  As  advanced  as  today’s  M&S  is,  it  is  no  substitute  for  the  incorporation  of 
live  forces  and  live  operations  into  Fleet  Battle  Experiments. 

Discussion:  Despite  the  second  half  of  TT03/FBE-K  being  called  a  “Field  Training 
Exercise”  (FTX),  there  were  no  live  forces  or  emitters  of  any  kind  used  for  the  FBE-K  ISR/JFN 
TST  events.  This  was  not  by  design,  by  any  means,  but  rather  became  a  forced  constraint  based 
on  the  realities  of  world  events  (such  as  “Gulf  War  II”)  and  other  forces  outside  the  control  of 
NWDC  planners. 

With  NWDC’s  extensive  M&S  operations,  FBE-K  TST  “players”  were  able  to  learn  and 
exercise  many  of  the  basic  processes  and  infonnation  flows  involved  in  TST.  The  simulation, 
however,  would  NOT  have  been  sufficient  to  support  any  of  the  more  complex  TST  and 
supporting  intelligence  processes  had  they  been  attempted,  processes  such  as  intelligence 
preparation  of  the  battlespace  (IPB),  collateral  damage  estimation,  targeting  of  precise  weapons, 
and  battle  damage  assessment  (BDA). 

In  addition,  current  M&S  state-of-the-art  simply  cannot  simulate  the  myriad  “devil’s-in- 
the-details”  type  factors  experienced  in  live-fly,  live-OPFOR,  and  live-fire  environments.  This 
is  primarily  due  to  the  complexities  of  human  interactions  with  other  humans  (e.g.,  the  complex 
interactions  it  takes  for  something  as  “simple”  as  the  aircrew  of  a  P-3  conducting  ISR  collection 
to  coordinate  with  the  analysts  aboard  the  ship  receiving  the  direct  downlink  of  their  video),  and 
with  their  environment  (both  physical,  technical,  cultural/morale,  etc.). 

While  today’s  M&S  is  good  for  many  types  of  focused,  limited  objective  experimentation 
(e.g.,  when  controlling  almost  all  variables  and  adjusting  only  a  few  to  compare  results),  it 
generally  by  itself  does  not  provide  as  good  an  environment  as  when  live  forces  and  operations 
are  incorporated  for  experimenting  with  new  military  CONOPS  and  TTP  where  human 
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interactions  (e.g.,  analysis,  decision-making,  and  enemy  actions  and  reactions)  and 
environmental  factors  are  significant  determinants  of  whether  those  CONOPS  and  TTP  are  of 
value  or  not. 

This  is  particularly  true  in  the  areas  of  ISR  and  targeting  where  so  many  of  the  processes 
are  analytic  in  nature.  The  “target”  of  the  analysis  has  to  be  as  complex  (e.g.,  active/reactive 
OPFOR  trying  to  remain  ellusive)  and  as  subjected  to  the  environment  (e.g.,  obscured  by 
weather  or  terrain)  as  in  “real  life”.  The  inverse  relationship  of  “time  to  analyze”  vs.  “quality  of 
analysis”  is  perhaps  the  single  most  difficult  issue  faced  in  ISR  and  targeting,  particularly  in 
support  of  activities  such  as  time  sensitive  targeting;  the  only  way  to  get  at  this  relationship  in  a 
meaningful  way  is  to  provide  the  level  of  fidelity  inherent  in  the  use  of  live  forces. 

Recommendation:  Conduct  all  future  ISR,  targeting,  and  JFN-related  experimentation 
with  as  many  live  forces  (including  live  OPFOR)  as  possible  to  increase  the  fidelity  of  the 
experiment  to  a  level  that  includes  as  many  of  the  “truly  hard”  analytic  processes  as  possible. 

SECTION  3:  FBE  TECHNICAL  AND  SYSTEMS  OBSER  VA  TIONS. 


3.1  Operational  Sequence  Diagrams. 

Observation:  Functional  Flow  Diagrams  (FFDs)  should  be  developed  prior  to  (or  in 
conjunction  with)  Operational  Sequence  Diagrams  (OSDs). 

Discussion:  One  type  of  document  that  has  been  a  key  part  of  FBE  planning  is  the 
Operational  Sequence  Diagram  (OSD),  a  graphical  depiction  of  what  computer  systems  are 
supposed  to  have  what  data/message  types  flow  between  them  over  what 
communications/network  paths  in  what  order  for  any  given  event  during  the  FBE.  While  OSDs 
are  extremely  useful  for  showing  the  “what,  where,  when,  and  how”  of  FBE  data  and 
information  flow,  they  do  not  adequately  address  the  questions  of  “who”  and  “why”  without 
which  the  OSDs  are  moot. 

During  FBE-K,  the  ISR  UUV  team  at  NUWC  developed  a  series  of  what  amounted  to 
functional  flow  diagrams  (see  Attachment  B)  that  gave  the  rationale  behind  the  technical  OSD 
that  was  in  turn  being  developed  to  show  how  the  vSSN  /  ISR  UUV  simulations  would  be 
connected  to  the  rest  of  the  NWDC  M&S  and  C4I  architecture.  Their  functional  flow  diagrams 
(FFDs)  not  only  laid  out  the  “who”  and  “why”  to  help  the  FBE  Technical  Team,  but  they  also 
greatly  facilitated  the  development  of  MSEL  events  and  related  aspects  of  FBE-K  planning. 

Development  of  FFDs  for  all  initiative  areas  would  go  a  long  way  to  ensuring  that  the 
supporting  OSDs  have  a  reasoned,  functional  underpinning.  This  underpinning  is  important  to 
ensuring  the  technical  architecture  optimally  supports  the  experimental  objectives,  and  because 
the  OSDs  inevitably  translate  into  the  expenditure  of  FBE  resources  (e.g.:  financial;  technical 
expertise;  systems,  networks,  and  communications;  OSD  testing;  training;  etc.) 

Recommendation:  For  subsequent  FBEs  (and  other  experimentation  events),  FFDs 
should  be  institutionalized  as  required  documents  for  all  initiatives,  to  describe  who  at  which 
functional  nodes  need  (or  will  provide)  what  information  from  (to)  whom  and  why.  The  OSDs 
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should  subsequently  (or  concurrently)  be  developed  as  the  technical  reflection  of  those  FFDs. 


3.2  Common  Operational  Picture  (COP). 

Observation:  The  COP  in  FBE-K  did  not  have  explicit  “ownership”  by  any  initiative, 
and  was  not  maintained  to  a  level  required  to  support  ISR  and  JFN  in  support  of  TST. 

Discussion:  The  COP  was  not  made  an  explicit  part  of  any  FBE-K  initiative,  despite  the 
fact  that  an  accurate,  stable  COP  is  foundational  to  most  (if  not  all)  of  them.  The  COP 
“ownership”  remained  unclear  in  FBE-K  (as  it  did  in  FBE-J),  most  likely  because  the  COP  is 
common  to  all  initiatives,  and  because  it  inherently  requires  the  relentless  attention  of  a  broad 
range  of  analysts  and  technicians,  all  operating  at  several  different  levels. 

There  are  technicians  who  must  establish  and  maintain  the  COP  engine(s)  and  the  CST 
services  at  major  nodes.  There  is  a  wide  a  variety  of  technical  and  analytic  feeds  into  the  COP, 
each  of  which  has  to  be  made  explicitly  responsible  for  providing  quality,  timely  data  (e.g., 
TDDS  filters,  Link  inputs,  Space/Missile  events,  weather,  etc.).  There  are  COP  analysts  of 
varying  disciplines  (e.g.,  ISs,  OSs,  CTs,  AGs)  who  must  provide  quality  assurance  (QA)  for  their 
particular  “piece(s)”  of  the  COP  (e.g.,  red  tracks,  blue  tracks,  air  tracks,  subsurface  tracks, 
filters/alerts,  etc.),  and  the  databases  associated  with/supporting  the  COP  (maps/charts/overlays, 
EOB,  MIDB,  imagery  catalogs). 

Without  the  explicit  involvement  and  coordination  of  all  (or  at  least  most)  of  these 
analysts  and  technicians,  the  COP  will  be  of  such  a  poor  quality  as  to  be  largely  ignored. 

Despite  FBE-K  being  the  first  FBE  to  have  a  successful  display  of  all  Blue  ISR  assets  in  COP 
with  appropriate  labels,  the  COP  in  general  was  rudderless,  and  was  all  but  useless  to  ISR  and 
JFN  in  support  of  TST. 

Recommendation:  Early  in  the  FBE  planning  stages,  identify  who  has  responsibility  for 
each  of  the  many  complex,  interdependent  functions  that  go  into  producing  an  accurate,  stable 
COP  from  which  players  will  be  capable  of  “fighting  the  experiment”  (instead  of  fighting  with 
the  COP).  Consider  doing  the  same  with  other  “foundational”  FBE  processes,  depending  on  the 
nature  of  the  experiment. 

3.3  Tactical  Exploitation  System  -  Navy. 

Observation:  FBE-K  reconfirmed  that  TES-N  has  a  number  of  powerful  tools  (some  of 
which  are  unique  to  TES-N)  that  potentially  could  be  of  great  use  to  Naval  forces  involved  in 
Time  Sensitive  Targeting  (TST).  Unfortunately,  FBE-K  also  reconfirmed  that  TES-N  remains  a 
very  complex  and  developmentally  immature  system,  with  extremely  limited  interfaces  to  other 
C4I  systems  that  are  critical  to  TST,  in  particular  GCCS-M  and  ADOCS. 

Discussion:  TES-N  was  used  in  FBE-K  to  support  TST  events,  along  with  the  other  two 
major  components  of  the  Joint  Fires  Network  (JFN),  namely  GCCS-M  and  JSIPS-N.  The  major 
inputs  to  TES-N  during  FBE-K  were  from  a  variety  of  M&S  systems  providing  simulated 
ELINT,  COMINT,  ISR  video,  national  imagery,  and  U-2  imagery  and  platform/sensor  telemetry. 
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TES-N  was  also  supposed  to  receive  track  data  from  GCCS-M,  but  this  capability  was 
functionally  unusable  due  to  the  fact  that  TES-N  does  not  provide  any  on-screen  labeling  of  the 
symbols/icons  used  to  display  GCCS-M  tracks. 

The  TES-N  video  display  and  capture  application  was  generally  reliable,  but  has  a 
strange  software  bug  in  that  the  user’s  video  control  icons  (e.g.,  start,  stop,  capture,  etc.)  do  not 
display  upon  initially  opening  the  window  until  the  user  moves  the  cursor  over  that  area  in  the 
window  (i.e.,  on  the  border  between  the  video  frame  itself  and  the  upper  edge  of  the  window). 
Also,  the  internal  handling  of  video  in  TES-N  degrades  the  signal  such  that,  by  the  time  the 
video  was  displayed  on  the  TES-N  Multi-Function  Workstation  (MFWS),  the  quality  of  the 
video  simulation  was  barely  useable  for  the  purposes  of  having  TES-N  users  “go  through  the 
motions”  of  Time  Sensitive  Target  (TST)  detection  and  identification.  For  instance,  the  NWDC 
Facilitators  on  BLR  would  often  have  to  go  to  another  space  on  BLR  to  read  the 
latitude/longitude  readout  on  the  video  remote  server  screen,  as  those  same  numbers  were 
illegible  on  the  TES-N  screen.  As  in  MC02/FBE-J,  TES-N  could  not  do  any  parsing  or 
processing  of  the  telemetry  data  provided  by  the  ISR  video  platform  M&S  system  other  than 
display  it,  on-screen,  “burned  in”  as  part  of  the  video  images  themselves.  This  resulted  in  the 
manual  entry  of  data,  particularly  latitude/longitude,  into  the  TES-N  target  nomination  creation 
template,  significantly  increasing  both  the  time  required,  and  the  risk  of  data  entry  errors. 

The  attempt  to  use  the  SCI  side  of  TES-N  during  FBE-K  revealed  that  TES-N  does  not 
have  any  true  COMINT  analysis  tools  (as  does  SCI  GCCS-M),  other  than  allowing  the  viewing 
of  SCI  messages  such  as  KLIEGLIGHTS  or  TACREPS,  and  the  plotting  of  locational  data  on  a 
map  —  both  of  which  SCI  GCCS-M  already  does  (and  in  C7F  cryptologists’  view,  does  better). 
For  this  reason,  C7F  cryptologists  (along  with  the  rest  of  the  Navy’s  cryptologic  community  —  at 
least  according  to  the  C7F  Fleet  Cryptologist)  have  chosen  to  not  use  TES-N  for  COMINT 
analysis.  Consequently,  none  of  the  required  connectivity  (other  than  JWICS  Intelink  web¬ 
browsing  access,  and  SCI-level  chat)  for  using  SCI  TES-N  was  not  in  place  for  use  during 
TT03/FBE-K.  While  attempts  were  made  to  effect  this  connectivity  during  TT03/FBE-K,  the 
effort  was  seen  by  NWDC  Facilitators  and  C7F  personnel  as  being  low  priority  compared  to 
other  issues  being  dealt  with  simultaneously  (both  in  TT03/FBE-K  and  in  the  “real  world”),  so  it 
never  got  done.  Furthermore,  a  key  part  of  the  concept  of  using  SCI  TES-N  for  the  COMINT 
analyst  member  of  the  TST  team  was  to  exercise  use  of  the  Information  Support  Server 
Environment  Guard  (ISSE)  Guard  to  move  appropriate  data  from  the  SCI  side  of  TES-N  to  the 
GENSER  side  of  TES-N  in  support  of  TST  processes.  Unfortunately,  no  BLR/C7F  personnel, 
TES-N  FSRs,  or  JFN  Mobile  Training  Team  (MTT)  members  knew  anything  about  configuring 
or  operating  the  ISSE  Guard. 

TES-N’s  primary  output  was  supposed  to  be  automated  TST  target  nominations  (USMTF 
messages  in  ATI.ATR  format)  to  four  places:  (1)  to  GCCS-M  to  update  the  situational 
awareness  (SA);  (2)  to  JSIPS-N’s  PTW,  with  relevant  imagery  attached,  for  image  analysis  and 
aimpoint  generation;  (3)  to  a  prototype  web-based  TST  Target  Folder  server  (set  up  for  the  FBE 
at  NWDC)  again  with  relevant  imagery  attached;  and,  (4)  to  ADOCS  to  begin  engagement 
processes  such  as  weapon-target  pairing. 

Almost  immediately  after  the  first  successful  ATI.ATR  output  by  TES-N  (four  days  into 
the  FBE’s  CPX),  ADOCS  users  began  complaining  that  the  TES-N  analysts  were  not  giving  the 
nominated  targets  a  proper  target  identification  (TGTD).  Two  days  later  (i.e.,  on  the  last  day  of 
CPX),  inconsistencies  were  noticed  in  how  the  target  nominations  were  being  handled  by 
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ADOCS  and  how  they  were  showing  up  in  the  TST  Target  Folder  server.  Not  until  late  in  the 
evening  of  FTX  day  five  was  controlled  testing  able  to  be  done  by  the  NWDC  Facilitator,  during 
which  fault  was  found  in  both  TES-N  and  ADOCS.  Part  of  the  confusion  was  because  the  TES- 
N  target  nomination  creation  template  allows  the  analyst  to  give  the  target  an  identification  (e.g., 
type,  equipment  name,  etc.)  using  either  the  “TST”  or  the  “TGTD”  lines,  but  not  both.  ADOCS, 
on  the  other  hand,  apparently  only  uses  the  “TGTD”  line  for  target  identification.  For  instance, 
when  the  TES-N  ATI.ATR  message  used  the  “TST”  line,  ADOCS  would  “turn  around”  to  the 
TST  Target  Folder  server  an  ATI.ATR  with  no  “TST”  line  and  a  blank  “TGTD”  line  (e.g., 
“TGTD/-//-//”);  whereas,  if  the  TES-N  message  used  the  “TGTD”  line,  ADOCS  would  “turn 
around”  an  ATI.ATR  with  both  a  “TGTD”  line  (whose  fields  were  out  of  order  and  truncated 
compared  to  the  original  ATI.ATR)  and  at  “TST”  line  (containing  the  same  fields  as  “TGTD” 
line).  ADOCS  also  changed  several  other  fields  of  other  lines  for  no  known  reason,  most 
notably  the  “DTG”  line  and  field  contents. 

Even  in  TES-N  version  5.0  (the  version  used  in  FBE-K),  analysts  faced  the  same  problem 
encountered  in  FBE-J  in  that  they  could  not  attach  images  to  outgoing  ATI.ATR  messages. 
Consequently,  all  images  captured,  “chipped”  and  saved  (as  NITF)  in  TES-N  had  to  be  manually 
transferred  (FTP)  to  PTW.  The  PTW  operator  would  then  pull  up  the  images  and  conduct 
aimpoint  refinement  (only  sometimes,  due  to  manning  constraints  and  base  image  quality  issues 
—  see  “M&S  FEEDS  INTO  TES-N”  section  above),  and  then  save  the  images  (as  both  JPEG  and 
NITF)  to  a  shared  directory  on  the  BLR  IT-21  LAN.  The  workaround  for  getting  images  into  the 
TST  target  folders  was  for  the  NWDC  Facilitator,  and  later  some  of  the  players  (once  the  were 
taught)  to  use  MS  Outlook  on  an  IT-21  machine  to  manually  create  a  one-line  ATI.ATR  email 
(using  the  “TNO”  line  only)  with  the  subject  line  “Target”,  pull  the  image(s)  from  the  shared 
directory  and  attach  to  the  email,  and  then  send  the  email  and  attached  images  to  the  TST  Target 
Folder  server.  The  server  would  then  parse  the  email,  and  use  the  “TNO”  to  update  the  correct 
target  folder  with  both  the  ATI.ATR  info  and,  more  importantly,  the  images  themselves. 

Similarly,  TES-N  version  5.0  brought  no  improvement  in  TES-N’s  ability  to  output  to 
GCCS-M  from  what  was  used  in  MC02/FBE-J.  In  fact,  the  capability  did  not  exist  on  BLR  until 
the  NWDC  Facilitators  came  aboard  and  showed  the  C7F  staff  how  the  creation  of  a  “Manual 
Contact”  in  TES-N  at  the  same  location  as  the  nominated  TST  (which  was  already  in  TES-N’s 
Cross-INT  database  and  was  displayable  using  TES-N’s  Integrated  Tactical  Display  [ITD] 
application)  could  be  set  up  to  be  sent  periodically  as  a  formatted  message  (OTH-Gold  or 
XCTC)  to  GCCS-M’s  JOTS1.  It  took  the  entire  CPX  to  focus  enough  time  and  energy  to 
troubleshoot  this  interface  and  get  it  working.  It  worked  for  the  first  two  days  of  FTX,  and  then 
suffered  the  same  problem  as  the  TES-N  target  nominations  when  TES-N  “crashed”  for  a  few 
days  (i.e.,  nothing  could  be  saved  to  the  Cross-INT  database)  and  was  never  able  to  be  brought 
back  up  —  consequently,  the  GCCS-M  “Red  database  analyst”  was  never  able  to  become  part  of 
the  TST  process  (e.g.,  changing  the  “hard-wired”  TES-N-assigned  track  name  to  reflect  the 
Target  Block  Number  assigned  to  that  TST  by  TES-N  during  the  target  nomination  creation 
process).  Bottom  line:  the  TES-N  output  to  GCCS-M  only  worked  for  two  days  at  the  same 
rudimentary  and  suboptimal  level  at  which  it  was  working  for  MC02/FBE-J;  for  the  remainder  of 
TT03/FBE-K  it  was  functionally  inoperative. 

See  Attachments  C  and  D  for  a  more  detailed  treatment,  and  for  additional  issues. 

Recommendation:  Don’t  use  TES-N  in  any  further  TST-related  experimentation  until 
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major  advances  are  made  to  at  least  the  following:  (1)  interface  with  ADOCS;  (2)  interface  with 
GCCS-M;  (3)  interface  to  PTW  and  any  external  target  folder  applications  (e.g.,  attachment  of 
image  chips  to  ATI.ATR  messages);  (4)  handling  of  ISR  video  and  platform/sensor  telemetry; 
and,  (5)  SCI  COMINT  analysis  tools,  and  SCI-to-GENSER  connectivity  via  ISSE  Guard. 
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Appendix  E  FBE-Kilo  OBSERVATIONS  -  FIRES  PLANNER 

This  Appendix  was  provided  by  Steve  Wood  of  Booze,  Allen,  Hamilton  Corporation 


Section  1 :  FBE  Kilo  and  FBE  Kilo  Sea  Strike  Operational  Planning  Observations. 

1.1  Planning  Directive 

Observation:  No  experiment  directive  was  published  for  this  FBE. 

Discussion:  In  the  past,  experiment  directives  (in  message  fonnat)  have  been  used  to  codify  and 
document  the  responsibilities  of  various  NWDC,  the  numbered  fleet,  and  the  various  DON 
agencies  (both  operational  forces  and  shore  establishment).  Published  by  CCFC  in  coordination 
with  NWDC  and  the  numbered  fleet  participating  in  the  FBE,  its  is  a  rosseta  stone  of  information 
that  outlines  responsibilities,  functions,  and  path  toward  execution  of  the  experiment  event.  The 
lack  of  this  document  can  cloud  fleet  numbered  responsibilities  and  makes  “arrangements”  for 
support  non-binding  and  unofficial. 

Recommendation:  Use  this  instrument  in  every  FBE  and  LOE  that  is  conducted. 

1.2  Forward  FBEs  and  NWDC  Fleet  Presence 

Observation:  Forward  presence  by  the  NWDC  staff  and  key  planners  was  lacking. 

Discussion:  Forward  fleets  require  constant  attention  during  the  FBE  planning  process.  During 
FBE  Kilo,  uniformed  initiative  leads  were  present  at  the  forward  fleet  toward  the  end  of  the 
planning  process,  but  many  of  the  other  key  planners  did  not  interact  with  the  fleet  on  a 
substantial  basis  until  they  arrived  for  execution  of  the  experiment.  One  way  to  foster  this  is 
through  conduct  of  the  FPC  at  the  hosting  numbered  fleet  location. 

Recommendation:  Attempt  to  get  key  planners  forward  often  in  the  planning  process  and 
ALWAYS  hold  the  Final  Planning  Conference  at  the  forward  numbered  fleet  home  location. 

This  will  leverage  fleet  interaction  and  participation. 

1.3  Fleet  Interface  and  Fleet  Initiative  Sponsors 

Observation:  No  uniformed  numbered  fleet  sponsor  (unifonned  warfighter)  for  the  Sea  Strike 
Initiatives  was  identified  or  utilized. 

Discussion:  The  Sea  Strike  Initiatives  did  not  have  substantive  uniformed  numbered  fleet 
representation  throughout  FBE  Kilo  (planning  and  execution).  Not  having  warfighter 
sponsorship  at  the  numbered  fleet  level  for  FBE  initiatives  that  focus  on  the  application  of 
sensors  and  weapons  on  high  value  emergent  targets  is  unacceptable. 

Recommendation:  Use  the  experiment  directive  to  outline  the  fleet  sponsorship  requirement  and 
don't  examine  initiatives  that  have  no  unifonned  sponsorship  within  the  numbered  fleet  staff. 
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1.4  Technical  versus  Operational  Initiatives 

Observation:  Many  modeling  and  simulation  (DDX  ANGUSS,  DISCOVERY  MACHINE, 
WALTS)  initiatives  that  were  never  part  of  the  overall  experiment  plan  (integrated,  briefed  or 
otherwise)  impacted  experiment  execution. 

Discussion:  While  many  of  these  diversions  could  have  been  worked  into  the  operational 
experiment  plan,  they  were  not.  This  caused  friction  during  execution  was  not  supporting  of  the 
Sea  Strike  Initiatives  as  briefed  and  approved  by  the  FBE  director. 

Recommendation:  Identify  ALL  initiatives  up  front  and  make  sure  they  are  part  of  the 
experiment  plan.  Include  the  TEP  (Technical  Engineering  Plan)  as  a  supporting  potion 
experiment  plan  rather  than  as  a  standalone  document.  The  Explan  needs  to  codify  ALL 
initiatives  that  are  being  undertaken  and  work  to  integrate  those  efforts. 

Section  2 :  FBE  Kilo  and  FBE  Kilo  Sea  Strike  Operational  Execution  Observations. 

2.1  Training 

Observation:  No  window  for  training  users  (fleet  or  reserve  force)  on  the  experimental  C4I 
(xC4I)  systems  used  in  the  FBE. 

Discussion:  In  the  last  couple  of  FBEs,  this  was  accomplished  in  spiral  events.  There  was  no 
such  event  in  FBE  Kilo.  This  lead  to  several  days  of  training  during  experiment  execution, 
resulting  in  the  loss  of  experiment  process  analysis  time. 

Recommendation:  Build  spiral  events  or  dedicated  FBE  training  windows  into  the  schedule. 
Publish  that  schedule  and  those  placeholders  in  the  experiment  directive. 

2.2  IKA  Support 

Observation:  IKA  support  to  the  FBE  was  minimized  due  to  MBC  participation  in  the  2nd  Fleet 
LOE.  There  was  no  coordinated  IKA  support  for  FBE  execution.  (A  web  portal  that  participants 
can  post  to  in  NOT  IKA.) 

Discussion:  No  IKA  lead  planning  or  execution  support  for  the  FBE  was  responsible  for  many 
delays  and  training  problems.  Adhoc  /  initiative  level  IKA  measures  had  to  be  implemented  on 
the  fly  to  support  FBE  execution.  To  exacerbate  this  matter,  no  clear  level  of  IKA  support  was 
ever  articulated  to  the  planners  in  light  of  this  during  the  planning  process. 

Recommendation:  Identify  IKA  (or  other  initiative  area)  participation  level  in  FBE  and  ensure 
that  it  is  maintained. 

2.3  Reserve  Support  Utilization 

Observation:  Many  reservists  were  utilized  in  FBE  Kilo  to  facilitate  execution. 

Discussion:  This  was  a  bright  spot.  Reserve  personnel  were  plentiful,  well  coordinated  and 
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quite  supportive  to  the  FBE  effort.  This  was  the  best  coordinated  reserve  support  effort  in  an 
FBE  to  date. 


Recommendation:  Continue  to  work  with  the  reserve  forces  at  the  level  reached  in  FBE  kilo  to 
support  future  FBEs 

2.4  Fleet  Execution  Support 

Observation:  Numbered  fleet  staff  support  was  abysmal  for  the  Sea  Strike  Initiatives.  Support 
was  limited  to  a  civilian  science  adviser  and  two  junior  officers.  This  extended  to  JIC  support 
for  JFN  manning  during  the  CPX.  (1  E-6).  The  promised  JFACC  support  was  also  minimal  (3 
junior  officers)  and  not  what  had  been  planned  for. 

Discussion:  This  lack  of  support  in  all  these  area  was  the  largest  single  factor  in  not  realizing  the 
experimental  potential  of  the  Sea  Strike  efforts  in  FBE  Kilo.  This  could  be  seen  during  the 
planning  process  but  was  not  corrected  by  the  MBC  uniformed  staff. 

Recommendation:  Early  and  frequent  interaction  with  the  UNIFORMED  staff  at  the  ACOS 
level  is  required  for  ALL  initiatives  in  an  FBE,  especially  one  held  within  a  forward  numbered 
fleet. 


2.5  Execution  Timeline 

Observation:  The  Sea  Strike  initiatives  covered  to  long  a  period.  (24  days) 

Discussion:  It  is  impossible  to  coop  a  numbered  fleet  staff  for  this  period  of  time  to  conduct  an 
experiment  and  still  get  a  proper  level  of  focus  from  that  staff.  Executing  FBE  events  over  a 
period  this  long  leads  to  complacency  and  lack  of  desire  to  continue  on  the  part  of  the 
participants.  This  lesson  had  already  been  learned  in  FBE  Juliet. 

Recommendation:  Limit  initiative  efforts  to  a  5-8  day  period  with  adequate  training  on  the  front 
end  to  support  the  desired  efforts. 


Section  3 :  FBE  Kilo  and  FBE  Kilo  Sea  Strike  Backdrop  /  Scenario  Observations. 


3.1  FBE  overlay  on  Exercise  Construct 

Observation:  FBE  Kilo  construct  only  loosely  fit  the  Tandem  Thrust  03  construct. 

Discussion:  The  overall  FBE  construct  that  was  layered  over  the  exercise  construct  was  adequate 
for  execution  had  the  exercise  construct  been  completed.  Database  testing  for  the  event  was 
woefully  lacking  and  joint  force  (JFACC)  participation  was  almost  nonexistent.  This  resulted  in 
errant  databases  (MIDB,  AODB,  BSCMs),  that  did  not  function  properly.  Initiative  and 
technology  reliance  on  this  infonnation  suffered  through  execution  because  of  this.  While  this 
may  have  been  out  of  the  NWDC  purview  for  the  FBE,  it  highlighted  that  even  for  a  tier  1  level 
JTF  event  that  database  integrity  should  not  be  assumed. 
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Recommendation:  Planner  and  technologies  must  participate  in  any  exercise  database  testing 
events  that  are  integrated  into  the  FBE  construct. 

3.2  Exercise  Augmentees 

Observation:  C7F  only  received  a  small  percentage  (+/-  30%)  of  the  planned  staff  augmentation 
and  component  augmentation  that  was  required  to  carry  out  the  Sea  Strike  initiatives. 

Discussion:  Events  beyond  the  control  of  both  the  MBC  and  the  numbered  fleet  resulted 
manpower  shortages  that  greatly  hindered  the  FBE  effort.  While  these  may  have  been 
unavoidable,  they  were  foreseen.  At  some  point  prior  to  execution,  manning  go/no  criteria  need 
to  be  established  and  utilized  to  prevent  execution  of  events  just  for  the  sake  of  “doing 
something.”  This  position  must  be  reached  in  concurrence  with  the  numbered  fleet  staff  and  the 
decision  to  execute/not  execute  made  as  the  result  of  this  prior  agreement. 

Recommendation:  Institute  manning  go  /  no  go  levels  during  the  planning  process.  Do  this  in 
concurrence  with  the  numbered  fleet.  Be  prepared  to  not  execute  portions  of  an  FBE  if  these 
criteria  are  not  reached. 

3.3  Scenario 

Observation:  FTX  scenario  did  not  match  (very  closely),  the  FBE  Sea  Strike  live  force  scenario. 

Discussion:  This  problem  was  due  in  most  parts  to  the  CJTF  (C7F)  fighting  the  sim  and  live 
scenarios  together  when  they  were  designed  to  be  separate.  While  it  may  be  out  of  the  MBC’s 
control  to  drive  this  during  execution,  there  is  room  to  avoid  this  by  properly  planning  prior. 
Many  FBE  have  used  this  detached  live  /  sim  event  construct  successfully,  but  only  when  the  full 
staff  and  the  fleet  commander  himself  is  intimately  familiar  with  the  scenario  /  events.  This  was 
not  the  case  in  FBE  Kilo.  This  problem  is  directly  related  to  lack  of  numbered  fleet  involvement 
in  the  planning  cycle. 

Recommendation:  Force  a  higher  level  of  fleet  experiment  /  exercise  integration  familiarization 
early  and  often  in  the  planning  process. 

3.4  Assumptions  and  Required  Products 

Observation:  Am  assumption  was  made  by  the  FBE  planning  staff  that  certain  products  required 
for  FBE  execution  (AODB,  MIDB,  BSCMs,  etc...)  would  be  available. 

Discussion:  Even  though  this  was  a  tier  1,  JWFC  coordinated  and  congressionally  mandated 
event,  the  database  test  was  inadequate.  This  resulted  in  errant  information  for  use  in  the  XC4I 
systems  used  during  the  FBE.  This  caused  many  problems  throughout  the  execution  cycle. 

Recommendation:  NWDC  must  participate  with  both  planners  and  technologies  in  the  database 
test  process.  If  products  required  are  substandard,  then  they  must  be  identified  and  corrected 
prior  to  execution 
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Section  4:  FBE  Kilo  and  FBE  Kilo  Sea  Strike  Technical/  xC4I  Observations. 


4.1  Shipboard  System  Specifications 

Observation:  USS  Blue  Ridge  has  a  10  mb  switch  backbone  that  is  connected  via  155  mb  links. 
This,  along  with  inconsistent  network  card  setting  hindered  ADOCS  use  during  the  FBE. 

Discussion:  Standard,  shipboard  LAN  configurations  that  support  ADOCS  usage  need  to  be 
established.  This  applies  to  switch,  link,  and  network  card  settings  on  these  machines. 

Hardware  limitations  may  require  platfonns  to  set  up  multi-server  configurations  to  reduce  the 
effect  of  less  modern  network  backbones. 

Recommendation:  Set  ISNS  ADOCS  standards  prior  to  install  and  configure  accordingly. 

4.2  Recommended  Shipboard  System  Configurations 

Observation:  USS  Blue  Ridge’s  LAN  will  require  specific  ADOCS  configurations  to  support 
usage  on  that  platform. 

Discussion:  To  reduce  the  effect  of  a  less  modem  backbone,  placement  of  ADOCS  servers  in  a 
multiserver  configuration  is  required.  Also  standardization  of  network  interfaces  is  required. 

Recommendation:  Place  ADOCS  servers  in  the  following  spaces:  JIC,  JOC  (master),  JAOC. 
Configure  these  machines  so  they  are  all  pointed  at  the  same  switches  as  the  clients  they  support 
reside. 


4.3  ADOCS  recommend  software  /  hardware  changes 

Observation:  Many  recommended  changes  to  ADOCS  were  compiled  during  the  FBE. 

Discussion:  ADOCS  changes  are  indicative  of  command  and  control  capability  requirements 
that  currently  exist.  The  changes  are  catalogued  below. 

Recommendations: 

Software 

1 .  Ability  to  pair  a  target  to  an  ITO  mission  via  a  button 

2.  Ability  to  highlights  targets  in  Fires  and  JSTM  managers  when  changes  have 
occurred...  alert? 

3.  A  configurable  Fires  Manager  (within  the  ADOCS  GUI). 

4.  Add  “hour  glass”  icon  to  ADOCS  to  display  system  working. 

5.  TST  supported  CDR  indicator  in  JTSTM. 

6.  Hot  link  to  ROE  url. 

7.  Hot  link  to  TST  priorities  url. 

8.  Creation  of  a  Combat  Assessment  manager  and  removal  of  that  function  from  the  Fires/JTST 
managers. 

9.  Hot  link  to  target  folder  url. 

Hardware 

1 .  Two  (2)  displays  for  ADOCS  users  that  are  doing  target  development  and  coordination 
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4.4  JFN  interaction  with  ADOCS 

Observation:  ATI.ATR  target  nomination  from  JFN  was  incomplete. 

Discussion:  ATI.ATR  target  nomination  to  JFN  was  incomplete  and  not  really  viable  for  usage. 
This  problem  needs  to  be  fixed.  It  was  identified  over  2  years  ago  and  is  still  a  problem. 

Recommendation:  Detailed  ADOCS  -  JFN  testing  to  fix  this  problem.  This  should  be 
completed  in  a  lab  setting  vice  waiting  for  another  FBE. 


Section  5 :  Operational  Road  Ahead  and  other  Recommendations 

5.1  ADOCS  Road  Ahead  for  C7F  /  COMPACFLT  /  USPACOM 

Observation:  ADOCS  will  be  integrated  into  the  PACOM  C2  structure.  FBE  Kilo  was  a  major 
event  in  this  transition. 

Discussion:  ADOCS  use  in  FBE  Kilo  was  the  first  in  a  series  of  event  that  will  proliferate 
ADOCS  across  the  PACOM  AOR  (it  is  already  in  the  USFK  AOR).  Lesson  learned  for  this 
effort  (FBE  Kilo)  should  be  passed  on  to  facilitate  a  higher  level  of  functionality  in  future 
PACOM  events  (IPD,  TF04,  CG04). 

Recommendation:  Pass  detailed  ADOCS  report  to  PACOM  via  C7F  and  COMPACFLT  to  help 
this  effort  along.  Report  should  be  a  NWDC/JPSD  collaborative  effort. 

5.2  Time  Critical  Targeting  Functionality  Afloat  (TCTF  Afloat) 

Observation:  The  Xray  Papa  cell  was  an  excellent  test  case  for  familiarization  of  the  TCTF 
concept  to  the  fleet. 

Discussion:  TCTF  is  a  USAF  program  that  outlines  the  C2  requirements  and  systems  for 
conducting  time  critical  targeting  operations.  In  support  of  JCC  and  JCC  (Afloat),  the  USN 
needs  to  further  refine  this  concept  to  support  both  joint  and  maritime  forces  from  a  flag 
configured  platfonn. 

Recommendation:  Use  TCTF  Afloat  a  starting  point  for  Sea  Strike  initiatives  in  future  FBEs. 

5.3  Coalition  Fires  Experimentation 

Observation:  Coalition  shooter  information  requirements  where  not  met  by  the  RMG 
technology. 

Discussion:  The  RMG  technology  and  its  approved  rulesets  did  not  allow  the  coalition  forces  to 
fully  integrate  with  the  other  shooter  platforms.  This  problem  resulted  in  SA  deficiencies  on 
both  sides  of  the  guard. 

Recommendation:  Develop  two  paths  for  future  coalition  experimentation,  one  based  on  full 
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network  integration  and  the  other  based  on  LNO  supported  by  US  releasable  C2  systems  and 
backbone.  Both  are  viable  and  critical  to  continued  integration  of  coalition  forces. 

5.4  Xray  Papa  and  Maritime  Component  Time  Sensitive  Targeting 

Observation:  The  Xray  Papa  cell  identified  a  time  sensitive  targeting  gap  at  the  maritime 
component  level  that  needs  to  be  addressed. 

Discussion:  The  JFMCC’s  conduct  of  broad  scale  time  sensitive  targeting  operations  that  are 
integrated  with  other  components  is  beyond  the  traditional  role  of  the  Bravo  Papa  in  most 
instances.  A  staff  function  at  the  operational  level  (JFMCC)  that  supports  TST  prosecution  is 
required. 

Recommendation:  Integrate  this  effort  with  the  TCTF  effort  described  above  to  help  identify 
maritime  TST  command  and  control  requirements  of  the  future. 


Section  6 :  Other  Key  Insights  from  Experiment  Participants 


The  following  are  observations  from  FBE  participants  during  the  FTX  portion  of  the  FBE.  They 
are  a  source  of  information  for  how  people  felt  about  what  was  happening,  including  system 
performance. 

XP  Cell  Lessons  Learned  and  questions  from  26  April  2003 

ADOCS: 

-Though  the  speed  was  significantly  better  than  the  previous  day,  there  is  still  a  significant  time 
lag  from  mouse  click  to  display  response.  This  is  frustrating  to  the  user  and  detrimental  to 
timely  response  to  TST. 

-The  color  codes  for  target  coordination  need  to  be  defined.  There  is  probably  an  official 
standard  from  real  world  operations  that  can  answer  this  question.  (Note:  Colors  legend  is 
available  in  JTST  coordination  window,  which  would  be  useful  on  all  other  windows  where 
color  selections  are  possible.) 

-ADOCS/COP  -  was  not  updating  through  the  network.  Sometimes  took  several  minutes  for 
display  change  to  show  up  on  someone  else's  computer.  Current  thought  is  it  is  due  to  the 
limited  backbone  capability  of  the  system  on  board  LCC-19. 

-Administrative  -  commonality  between  systems.  Right  now  everything  is  wide  open,  anyone 
can  change  anything.  Need  database  manager  in  loop.  Example,  if  XP  is  rogering  up  for 
something,  then  he  should  be  the  only  one  that  can  control  that  function. 

-At  various  times  during  day,  all  machines  locked  up.  We  need  some  help  from  the  technicians 
to  identify  the  reason  for  these  occurrences. 

-Zoom  feature  reaches  a  point  that  causes  the  problem  where  Zoom  box  and  system  launches  out 
to  never-never  land. 

-Question  for  technicians:  Would  system  be  any  faster  if  we  use  fewer  ADOCS  stations? 

-  PROCESSES: 

-On  the  27th  we  will  attempt  to  run  one  target  completely  through  the  system  -  from  Nomination, 
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through  JIC/TST  Cell/XP/shooter.  While  running  this  end-to-end  thread,  we  will  record  steps  to 
establish  a  baseline  set  of  procedures.  In  order  to  make  this  most  useful,  we  need  technicians  on 
station  looking  over  our  shoulders  as  we  go  through  the  whole  process  to  ensure  we  are 
executing  in  the  most  efficient  manner. 

-Where  are  target  folders  set  up  and  how  will  we  be  made  aware  that  they  are  available? 
-Computer  setup  -  (for  future)  configurations  of  set  up  should  be  standardized. 

-Was  not  obvious  that  JIC  was  pushing  targets  up  to  XP.  And  if  they  did,  how  would  we  know 
that  they  did? 

-Who  can  push  targets  to  a  TST? 

-Only  people  that  can  push  target  should  be  the  ones  that  can  do  it  on  the  system. 
ORGANIZATION: 

-Chatrooms  -  no  idea  of  who  is  on  what/why/where.  Each  individual  watchstander  needs  to 
know  what  rooms  to  monitor.  (Note:  Fleet  commanders  publish  OPTASKs  to  specify  the 
procedures  for  using  Chat.  This  is  where  this  is  defined.) 

-How  does  XP  maintain  situational  awareness  of  ISR  assets  using  ADOCS? 

-There  is  currently  no  one  managing  ISR  assets.  Is  there  a  plan  for  JTF  to  do  this?  For  this 
experiment  is  the  ISR  manager  assigned  to  someone  in  the  JIC,  TST  Cell  or  the  XP  cell? 

C&C: 

-Though  there  is  a  UAV  TTP,  handoff  guidance  and  procedures  for  dynamic  retasking  of  UAVs 
is  not  clear.  Who  will  control  the  UAV  or  will  it  be  timeshared?  If  something  needs  to  be 
checked,  who  makes  the  decision  and  takes  control  of  UAV? 

OTHER: 

-JFN  terminals  in  the  TST  Cell  are  not  being  used.  It  was  also  noted  that  the  USAF  personnel 
manning  the  TST  Cell  are  under  direct  orders  to  not  use  or  even  look  at  JFN. 

-There  was  confusion  on  what  Chat  was  to  be  used.  The  direction  from  the  NWDC  FBE  team  is 
IRC  Chat.  The  procedures  for  setting  up  mIRC  Chat  was  drafted  by  LT  Powell  and  will  be 
distributed  to  all  participants. 


XP  Lessons  Learned  27  APR  03 

ADOCS: 

-Speed  of  response  to  operator  input  was  so  slow  it  was  unusable.  By  mid  afternoon,  ADOCS 
had  slowed  to  a  crawl.  It  was  taking  2-3  minutes  wait  time  for  system  response  after  each  key 
entry. 

PROCESSES: 

-Initial  position  of  TB0037  plotted  position  in  water  west  of  island.  JFACC  pushed  target  to 
JFMCC  (XP).  The  TBMCS  position  was  ok.  JIC  had  to  go  in  system  and  manually  re-enter 
coordinates.  Total  time  to  correct  entry  was  well  over  an  hour. 

-DDx  listed  CDCM  as  a  Cruise  Missile  Submarine  in  target  folder.  This  was  never  corrected 
even  after  bringing  to  attention  via  chat  and  telephone. 

-Control  of  UAV.  Not  as  many  assets  available  -  was  not  communicated  to  XP.  No  priority  in 
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tasking  limited  assets.  XP  can  establish  priorities,  but  there  was  a  lack  of  coordination.  DDx 
had  control  and  when  it  was  finished,  it  did  not  give  a  positive  hand-off  to  the  higher  authority  or 
to  the  next  unit  for  control.  So  UAV  just  flew  around  aimlessly  for  some  time. 

-Still  some  lack  of  positive  feedback  in  chat.  Example  is  TB0037  -when  we  requested  a  position 
confirmation,  we  did  not  get  an  feedback  that  they  were  working  the  issue. 

XP  Lessons  Learned  28  APR  03 

ADOCS: 

-Speed  of  response  to  operator  input  improved  significantly.  Operators  felt  it  was  still  slow  but 
usable. 

-BDA  -initially  there  was  no  way  to  change  color  on  that  tab.  This  was  corrected  prior  to  endex. 
-ADOCS  locked  up  with  system  fault  error. 

-Restrike  issue.  Confusion  over  what  the  restrike  function  does.  Recommend  ADOCS  be 
modified  to  have  restrike  field  show  old  mission  number  as  well  as  target  type. 

PROCESS: 

-Unless  testing  is  short  fused  due  to  malfunctions  in  system,  please  let  everyone  know  ahead  of 
time  that  test  tracks  are  going  to  be  entered  into  system.  This  will  preclude  spinning  wheels  on 
test  tracks. 

-Target  Positions:  Initial  position  has  been  incorrectly  entered  two  days  in  a  row.  Believe  this  is 
due  to  recording  wrong  lat/long  off  of  imagery?  This  was  noticed  due  to  targets  being  plotted  in 
water  on  ADOCS.  If  by  chance  they  were  wrong,  yet  plotting  on  land,  there  would  not  be  an 
easy  way  for  someone  to  catch  the  error. 

-Overall  process  is  becoming  clearer,  but  from  XP  ISR  viewpoint,  still  unsure  of  role  and 
information  flow. 

-E2  process  of  nominating  a  target  -  they  are  in  freeplay  mentality.  We  were  able  to  get  them  to 
push  a  target  into  ADOCS,  but  no  amplifying  information  (imagery,  etc.)  E2's  guidance  is  to 
attack  targets  that  meet  ROE.  They  were  in  ROTA  today,  which  was  not  in  operational  area. 
They  need  to  get  out  of  sim  mode  and  support  the  exercise. 

-E2  guys  need  to  review  days  ATO  and  work  within  confines  of  ATO. 

-DDx  was  not  given  control  of  UAV  today,  so  they  were  unable  to  id  targets. 

-TST  cell  does  not  have  a  fires  manager,  so  they  don’t  have  situational  awareness.  Recommend 
they  be  given  option  to  look  at  Fires  manager  to  know  when  mission  has  been  fired  by  the  ship. 
-Command  and  control  of  process  much  improved  today,  thanks  to  ADOCS  Tab  color  reference 
chart. 

XP  Lessons  Learned  for  29  APR  2003 

ADOCS: 

-Time  lag  between  here  and  DDX.  Example,  we  will  change  a  block  to  green  and  one  time  it  as 
long  as  5  minutes  for  it  to  show  up  at  DDX. 

-Recommend  system  permissions  be  put  in  place  for  ADOCS,  as  it  seemed  that  blocks  were 
being  changed  quite  often  by  the  wrong  team. 

-Fires  manager  often  would  not  update  automatically,  requiring  the  operator  to  close  and  reopen 
to  get  changes  to  show. 

-Deliberate  targets  were  interfering  somewhat  with  the  TST  processes.  Too  many  targets  were 
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in  the  queue  to  adequately  evaluate  and  take  action.  We  can  hide  the  ones  that  we  don’t  want  to 
see. 

-Confusion  on  who  was  submitting  TST.  Recommend  adding  something  in  ADOCS  so  everyone 
knows  who  is  nominating  to  TST.  You  actually  can  by  using  the  history  function. 

-According  to  Coalitions  Fires  in  NPT,  if  VANZAC  edits  ANZ  tab  (Missions  Coordination 
Manager)  it  fires  the  mission.  They  aren’t  editing  the  ANZ  tab.  ? 

-FDR  Block  (Missions  Coordination  Manager)  stayed  yellow  on  BLR  ADOCS  side.  Coalition  Fires 
side  of  ADOCS  after  weapons  release  was  showing  green.  Target  was  TB0041. 

-VANZAC  requested  guidance  on  number  of  ERGM  rounds  to  fire.  Cannot  specify  number  of 
rounds  in  ADOCS.  Does  unit  or  XP  detenninate  the  number  of  rounds  to  fire.  Actually  can 
specify  number  of  rounds  under  engagement  tab. 

-VANZAC  was  unclear  on  tab  protocol.  XP  developed  and  disseminated  tab  protocol  during  the 
exercise,  but  tab  protocol/documentation  required  prior  to  STARTEX  to  clarify  requirements  for 
exercise  participants.  I  recommended  this  to  Chris  Vogt  and  also  stated  that  in  order  to  properly 
operate  the  system  for  real  world  operations,  people  need  to  train  and  operate  the  system  in 
numerous  scenarios  for  30-45  days. 

-Multiple  ADOCS  system  down  times  hindered  play.  Chat  successful  in  engineering  work 
around  during  ADOCS  outages. 

-A  single  monitor  workstation  is  inadequate  for  an  ADOCS  operator.  It  is  our  opinion  that  the 
proper  set  up  for  an  ADOCS  operator  would  be  a  three  monitor  work  station,  VoIP,  and  a  phone. 

PROCESS: 

-CHAT  protocol.  Confusion  on  chat  -  due  to  large  numbers  of  people  on  ISR-COORD, 
sometimes  questions  were  not  responded  to.  Or  unanswered  for  long  periods  of  time. 
Recommend  all  players  leave  their  chat  windows  open  so  they  can  go  back  and  review  periods 
they  might  have  missed.  Other  channels  seemed  to  be  better. 

-Need  to  have  clearly  defined  chat  protocols  for  all,  with  the  right  players  monitoring  the  right 
chat  windows. 

-UAV  assets  were  often  not  available  to  support  PID.  ANZAC's  use  of  UAV  not  as  real  time  as 
DDx's  due  to  requirement  to  go  through  email  to  JIC. 

-Problem  with  target  folders  not  being  available  or  updated  for  a  period  of  time  in  afternoon. 

This  was  corrected. 

-Confusion  between  XP  and  DDx  during  lunch  hour.  Recommend  everyone  break  at  same  time 
formally.  UAV  schedule  for  DDx  included  our  lunch  hour,  so  they  effectively  lost  an  hour  of 
UAV  time. 

-  E2  wanted  to  control  options  for  WTP  of  airborne  assets.  XP  does  WTP  for  airborne  assets. 
-When  target  is  TST  and  fired,  who  fills  in  block  on  Fires  for  BDA  tab?  Recommend  in  Fires 
page,  firing  unit  inputs  to  XP  via  chat,  XP  update  BDA  block  on  Fires  and  then  JIC  turn  BDA 
box  on  TST  page. 

-Air  gap  latency  didn’t  appear  to  hinder  VANZAC  response  to  chat. 

-VANZAC  achieved  chipped  image  electronic  transfer  into  FBE-K  target  folders  at  NPT  for  web 
dissemination. 

JIC  Daily  Summary  for  26/27  APR  03 

ADOCS: 
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1.  Couldn’t  get  target  noms  from  TES-N  most  of  both  days  due  to  system  issues.  Work 
around  was  to  put  nominations  in  manually,  (see  Process) 

2.  Also  had  shut  down  of  conduit  which  passes  imagery  (with  metadata)  to  PTW  from  TES- 
N  resulting  in  inability  to  generate  aimpoints/mensurate  targets. 

3.  Recommend  for  future  experiments  with  ADOCS  tool  being  used  by  novice  players  that 
practical  training  be  provide  for  all  users  with  respect  to  the  role  they  will  play. 

PROCESS: 

1 .  Need  to  more  fully  define  process  requirements  for  manual  target  nominations 
particularly  with  respect  to  those  noms  which  should  be  coming  from  TES-N  (TB- 
designated  target  numbers)  but  don’t  because  of  system  down  problems.  There  needs  to 
be  a  fully  flushed  process  for  down  system  situations. 

2.  When  tasking  ISR  assets,  direction  needs  to  be  provided  on  releasing  the  asset  from  the 
request  once  collection  requirement  has  been  satisfied. 

3.  Need  to  establish  process  for  mapping  BHA/BDA  IRS  back  to  original  TST.  In  real- 
world  environment  data  flowing  in  from  multiple  sources  could  potentially  be  too 
voluminous  for  an  imagery  screener  or  analyst  to  randomly  pick  up  on  as  the  follow-on 
tasked  BHA/BDA  ISR  input  for  a  particular  target,  particularly  if  multiple  targets  are 
being  serviced  simultaneously. 

4.  (In  conjunction  with  #3)  Need  to  determine  whether  follow-on  imagery,  for  example,  for 
BHA/BDA  after  a  target  has  been  serviced  should  be  nominated  as  a  new  target  or  just 
mapped  to  original  target  nomination. 

5.  One  cause  of  today  (4/27)  TES-N  issues  had  to  do  with  database  log  files  filling  up  and 
saturating  the  server.  Sys/DB  Admin  process  needs  to  be  in  place  to  clear  log  files 
periodically  or  provide  warning  to  Sys/DB  Admin  contact  in  the  event  a  critical  quantity 
has  been  reached  before  a  set  clear  time  point. 

ORGANIZATION  SETUP: 

1 .  For  experiment  purposes  it  would  be  beneficial  to  have  an  organizational  setup  flushed 
that  mimics  real-world  hierarchy  with  clearly  defined  roles  and  responsibilities. 
Organizational  setup  for  the  experiment  should  be  documented  for  next  experiment  with 
brief  explanation  of  role  intentions/responsibilities.  Would  be  particularly  helpful  for 
manning  for  the  experiment  and  for  flushing  out  true  requirements  in  real-world  scenario. 

2.  Who  is  responsible  for  tasking  ISR  assets  for  BHA/BDA  imagery/assessment. 

3.  Who  is  responsible  for  assessing  effectiveness  of  strike  with  regards  to  a  serviced  target? 

And  for  updating  the  blocks  in  ADOCS. 

COMMAND  &  CONTROL: 

1 .  Need  to  clearly  define  who  can  task  ISR  assets  and  whether  there  are  any  restrictions  on 
directed  tasking. 

JIC  Daily  Summary  for  28  APR  03 

ADOCS: 

4.  TES-N  still  experiencing  problems.  Unable  to  obtain  stateside  support  through  the  night 
(Guam  time.)  Used  work-around  all  day  for  manually  submitting  target  noms  and  passing 
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imagery  to  ETFs  (electronic  target  folders).  Documented  procedures. 

5.  How  would  someone  know  in  ADOCS  that  multiple  target  noms/tst  in  either  (or  split 
between  both)  the  Fires  Manager  or  Joint  Time  Sensitive  Targets  Manager  are  associated 
with  one  another?  Or  is  this  relevant? 

6.  How  would  someone  know  from  looking  at  a  target  nom  in  the  Fires  Manager  in  ADOCS 
that  it  has  been  elevated  to  a  tst  already?  Or  is  this  relevant? 

7.  No  one  could  change  status  color  of  BDA  block.  Should  be  resolved  by  4/29  session. 

8.  ADOCS  training  should  include  an  example  of  requesting  re-strike  for  a  TST  and  how 
the  system  processes  this  input. 

9.  ADOCS  started  up  much  quicker  after  the  fix  for  the  BDA  color  block  not  being  editable. 

PROCESS: 

1 .  Need  to  resolve  process  with  regards  to  perfonning  a  re-strike  on  a  serviced  tst.  How 
should  the  target  nom  be  handled?  Issue  resolved  during  hot  wash  with  clarification  of 
how  ADOCS  system  handles  re-strikes;  i.e.,  a  new  TST  is  created  with  ‘-RESTRIKE’ 
appended  to  original  target  nom’s  description  (SA-06-RESTRIKE  in  today’s  event). 

2.  (Regarding  1)  To  clarify  for  others  what  a  new  TST  with  a  “-  Restrike”  descriptor  was 
generated  from,  the  controlling  component  who  recommends  the  original  TST  for  a  re¬ 
strike  (AB0024  in  today’s  event)  can  (this  worked  once  but  needs  validating): 

a.  call  up  the  new  re-strike  TST  in  the  JTST  Manager  (AB0027  in  today’s  event) 

b.  click  EDIT  on  the  TARGET  DATA  tab,  and 

c.  modify  the  DESCRIPTION  to  include  the  original  TST  target  number  (AB0024): 

New  Descriptor  for  AB0027:  SA-06-RESTR  AB0024 
Note:  There  is  a  18-character  limit  on  the  number  of  characters  that  will  display. 

3.  Did  not  know  how  to  contact  U2  POC  for  afternoon  event.  Didn’t  have  chat  handle  or 
other  contact  info. 

4.  JIC  is  struggling  with  providing  accurate  geo-coordinates  on  target  nominations  due  to 
the  poor  quality  of  the  simulated  video  feed  blurring  the  geo-coord  data.  This  can  be 
correct  with  better  video. 

ORGANIZATION  SETUP: 

1 .  Organization  structure  and  responsibility  seemed  smoother  today. 

COMMAND  &  CONTROL: 

1 .  Still  struggling  with  defining  who  controls  which  blocks  in  ADOCS  for  coordination  and 
planning  purposes.  Chart  provided  in  afternoon  should  resolve  much  of  this  confusion. 

OTHER: 

1 .  U2  imagery  initially  off  geographically  from  planned  event,  but  was  resolved. 

2.  U2  simulation  problem  caused  an  extreme  slow  down  in  exercising  the  afternoon  event. 

JIC  Daily  Summary  for  29  APR  03 

ADOCS: 

10.  TES-N  feed  working  much  better  today!  Be  advised  when  the  target  nominations  are 
submitted  directly  from  TES-N  to  ADOCS,  players  will  notice  approximately  a  10-min 
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lag  before  the  associated  image  will  appear  in  the  ETF. 

1 1 .  Can  ADOCS  not  be  designed  to  store  the  images  within  its  own  database  to  provide 
ready  access  to  individuals  managing  the  target  process  using  ADOCS? 

12.  Limitation  of  TES-N  nomination  screen  does  not  allow  operator  enough  target  TYPE 
choices  to  select  the  correct  one  in  most  instances  (for  e.g.:  SA-15  from  this  morning’s 
event  was  initially  entered  as  a  Heavy  Vehicle).  This  requires  modification  of  the  target 
nomination’s  target  TYPE  once  it  appears  in  ADOCS.  Could  be  confusing  to  individuals 
closely  monitoring  the  Fires  Manager. 

13.  In  the  afternoon  the  ETF  server  experienced  some  technical  difficulties  which  resulted  in 
ETFs  not  being  created  and  imagery  not  appearing  in  ETFs  for  E2  submissions  from 
GISR-C. 

14.  Acquired  date/time  group  not  populating  the  Target  Data  tab  of  the  Fires  Manager. 

15.  For  target  nominations  submitted  from  BLR  JIC  TES-N  stations,  the  NLT  dtg  is  being 
populated  incorrectly.  The  JIC  will  add  one  hour  to  this  dtg  in  their  noms. 

PROCESS: 

5.  To  keep  responsible  parties  informed,  add  the  Time-on-Target  data  to  the  Remarks  block 
of  the  Collection  Request  tab  (available  after  double-clicking  the  target  in  the  JTST 
Manager.) 

6.  The  JIC  Target  Officer  or  JFN  Operations  Officer  can  make  an  initial  recommendation 
for  a  target  nomination  to  be  raised  to  a  TST.  The  controlling  component  should  then 
validate  this  target  to  be  a  TST.  If  controlling  component  disagrees,  annotate  decision  in 
appropriate  block.  Then  move  the  target  from  the  JTST  Manager  back  to  the  Fires 
Manager  by  highlighting  the  target  and  selecting  from  the  menu  Tools  >  Target  to  Fires 
Manager. . . . 

7.  Wondering  if  the  images  submitted  by  GISR-C  operators  are  being  properly  attached  to 
the  nomination?  If  so,  need  to  research  why  the  images  are  not  showing  up  in  the  ETF 
folder.  This  deficiency  is  causing  confusion  in  the  process  with  regards  to  issues  like 
PID.  Note:  Have  not  been  able  to  find  an  image  in  an  ETF  except  one  processed  by  JIC. 

ORGANIZATION  SETUP: 

2.  Due  to  the  artificiality  of  the  experiment,  the  technical  setup  (what  systems  are  doing 
what  and  what  their  capabilities  are)  is  causing  some  confusion  with  who  should  be 
contacted  in  certain  situations;  For  e.g.:  to  see  streaming  video  feed  of  UAV  #2  and  for 
posting  a  missing  image  to  an  ETF  for  a  target  nomination  not  submitted  by  through  BLR 
JIC  TES-N. 

COMMAND  &  CONTROL: 

2.  Some  confusion  with  who  controlled  what  equipment  for  providing  tactical  data  for 
targeting.  Resolved  in  hot  wash  meeting. 

3.  Some  confusion  also  about  where  ISR  assets  should  be  allocated.  Detennination  was 
ISR  assets  should  not  leave  assigned  area  per  ISR  Sync  Matrix. 

4.  JIC  will  direct  ISR  assets  for  BDA  purposes  when  feasible. 

OTHER: 
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3.  Problems  with  telemetry  data  passing  from  the  U2  in  morning  disabled  ability  for 
imagery  screener  to  get  an  image  for  better  imagery  and  overview  shot  of  area  to  enhance 
PID  capabilities  and  improve  target  accuracy.  Could  not  run  this  scenario  concept. 

4.  A  problem  with  the  server  script  which  creates  the  ETFs  resulted  in  several  ETFs  not 
being  created  for  about  30  minutes  until  the  issue  was  resolved. 

JIC  Daily  Summary  for  30  APR  03 

ADOCS: 

16.  Still  some  confusion  as  to  who  controls  BDA  blocks  and  how  to  set  the  MSN  blocks  to 
provide  specific  status  of  a  target  being  prosecuted. 

17.  Updates  to  JTST  Manager  are  not  appearing  without  closing  and  re-opening  the  manager. 

18.  TB0041  showed  up  as  two  separate  TSTs  in  the  JTST  Manager  during  the  morning  event. 

The  system  is  not  suppose  to  allow  multiple  submissions  of  a  target  nom  to  TST 
Manager. 

19.  If  DTG  must  be  entered  with  a  4-digit  year,  ADOCS  Fires  Manager  >  Add  screen  should 
not  allow  the  target  nomination  to  be  entered. 

PROCESS: 

1 .  Confusion  regarding  JIC  ADOCS  target  nominations.  Need  to  put  one  in.  JIC  thought 
these  were  only  being  filtered  for  convenience  and  informed  others  of  new  ABxxxx  nom 
but  it  still  confused  everyone. 

2.  JIC  needs  clarification  on  what  everyone  expects  from  them  as  relates  to  the  JIC  tab. 

ORGANIZATION  SETUP: 

1 .  Need  to  have  clarification  on  BDA  input  responsibilities.  Who  is  tasking  assets  to  do  the 
collection,  who  is  collecting  and  assessing  imagery  for  it,  who  is  managing  the  color 
block? 

COMMAND  &  CONTROL: 

5.  Needs  to  re-fine  control  block  chart  for  ADOCS  coordination  tabs.  Need  to  include  most 
common  data  codes  which  appear  in  color  coordination  blocks.  E.g.:  EXE  in  Yellow 
MSN  block  in  JTST  Manager. 

6.  Working  on  better  situational  awareness  among  JFN  group. 

OTHER: 

1 .  Continued  problems  with  imagery  feed  and  telemetry  data  passing  from  the  U2. 


JIC  Daily  Summary  for  2  MAY  03 

ADOCS: 

20.  If  data  in  a  TST  coordination  tab  is  updated  and  saved  and  then  another  TST  is  selected, 
the  data  from  the  first  TST’s  coordination  tab  is  appearing.  This  is  confusing  when 
working  similar  targets.  One  thinks  the  data  has  been  updated  but  when  close  Modify 
window,  the  changes  do  not  appear  (b/c  they  weren’t  made  b/c  it  looked  like  it  was 


197 


updated  in  the  window.) 


PROCESS: 

3.  If  BHA/BDA  is  requested,  need  to  consistently  have  some  documentation  in  ADOCS  of 
TOT  either  on  the  Target  Data  tab  or  the  Collection  Request  tab  before  a  strike  is 
launched.  Recommend  always  setting  TOT  in  Target  Data  tab  because  time  shows  up  in 
the  main  JTST  Manager  window  to  the  left  of  the  PRI  column. 

4.  Re-strike  TST  entries  (eg:AB5088)  did  get  a  Target  Folder  created.  Created  one 
manually. 

ORGANIZATION  SETUP: 

2.  JFN/JIC  was  confused  about  if  collection  assets  were  needed  on  FDB  for  post-strike 
BHA/BDA  for  AA0366-AA0368.  BDA  assessment  was  provided  after  strike  in  Fires 
Manager  which  assessed  the  target  to  be  destroyed. 
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Appendix  F.  JFMCC  XP  TST  CELL  FOR  FEE  -  KILO 


The  following  is  a  Draft  document  describing  the  JFMCC  XP  Cell  TST  operations. 

Position  Titles  and  Job  Descriptions 

Duty  positions  and  functions  that  play  a  major  role  in  prosecuting  time  critical/time  sensitive 
targets  for  FBE-Kilo  are  listed  below.  These  duty  positions  are  identified  as  the  focal  points  for 
each  specialty  supporting  the  TST  Team. 

The  XP  Actual  may  call  JFMCC  TST  team  members  into  a  huddle  physically  or  virtually  as 
required.  The  minimum  number  of  personnel  required  for  Force-level  command  and  control 
(C2)  and  intelligence  support  for  prosecuting  time  sensitive  targets  within  the  JFMCC  is 
dependent  on  the  venue.  The  position  members  are  keyed  to  the  illustration  provide  at  Figure  1. 
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Plasma  Display 
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JFMCC 


XP  ANZAC 

XP  E2X 

Figure  1  JFMCC  XP  TST  Cell  Position  Titles  and  Job  Descriptions 


Duty  positions  and  functions: 


XP  Actual  (position  XP) 

•  Responsible  to  the  Joint  Force  Maritime  Component  Commander  (JFMCC)  for  the 
execution  of  the  TST  mission  within  the  JFMCC’s  designated  area  of  TST  responsibility. 

•  Retains  strike  authorization  authority  against  TSTs  within  the  area  designated  by  the 
JFMCC. 
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•  Directs  TST  operations  to  include  all  aspects  of  the  TST  operations  to  include  target 
nomination,  validation,  approval,  pairing,  coordination  and  execution. 

•  Authorize,  through  ISR  Operations  Officer,  redirection,  and  reallocation  of  JFMCC  ISR 
assets  to  include  all  aspects  of  the  TST  ISR  operations  to  include  approval,  pairing, 
coordination  and  execution. 

•  Briefs  JFMCC  as  required  for  TST  Ops. 

•  Coordinates  with  the  TST  mission  elements  on  at  least  a  daily  basis  if  not  more 
frequently. 

•  Coordinates  with  all  the  component  mission  commanders  on  TST  operations  issues  via 
daily  virtual  coordination  meetings. 

•  Reports  to:  Joint  Force  Maritime  Component  Commander  (JFMCC) 

•  Specialty:  Aviator  with  operational  strike/targeting  experience  and/or  Field  Grade 
Officer  with  extensive  operational  strike  experience  and/or  command  and  control 
expertise 

•  Workstation:  ADOCS,  SIPRNET  and  Collaboration  Application  (e.g.  mIRC) 

•  Links:  Secure  telephone  (STU-III)  link  to  JFMCC,  ADOCS  connectivity  to  JFACC 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

XP  Current  Operations  Cell  Chief  (position  XP  OPS) 

•  Responsible  to  XP  for  the  execution  of  his  routine  and  additional  duties  as  required. 

•  Responsible  to  the  XP  for  monitoring  the  execution  of  the  TST  mission  within  the 
JFMCC’s  designated  area  of  TST  responsibility,  and  advising  XP  on  any  problems. 

•  Coordinate  with  various  operational  control  agencies/commands  to  synchronize  and  de¬ 
conflict  TST  operations. 

•  Prepares  and  coordinates  responses  to,  and  daily  debrief  for  JFMCC. 

•  Coordinates  with  the  mission  elements  on  at  least  a  daily  basis  if  not  more  frequently. 

•  Reports  to:  XP 

•  Specialty:  Field  Grade  Officer  with  extensive  operational  strike  experience  and/or 
command  and  control  expertise 

•  Workstation:  ADOCS,  SIPRNET  and  Collaboration  Application  (e.g.  IWS) 

•  Links:  TBD 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

XP  ISR  Operations  Officer  (position  XP  ISR) 

•  Directs  ISR  assets  (UAV,  U2)  toward  emerging  potential  TST  for  collection. 

•  Provides  dynamic  tasking  requests,  for  assets  under  direct  control,  through  the 
appropriate  platform  LNO  if  that  asset  can  prosecute  the  target  without  impacting  the 
current  collection  plan. 

•  Coordinates  with  the  UAV  and  other  ISR  assets  to  optimize  sensor  collection  and 
reposition  allocated  ISR  assets’  collection  capabilities  to  obtain  best  quality  image  for 
TST. 

•  Maintains  liaison  with  JTF/JFACC  ISR  Operations  Office r(s)  for  dynamic  re-tasking 
requests  of  ISR  assets  not  under  direct  control. 
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•  Develops  and  submits  inputs  to  collection  management  plan  to  support  TST  objectives. 

•  Coordinates  on  IMINT  precision  geolocational  points,  collateral  damage  estimates,  no¬ 
strike  de-confliction,  and  weaponeering  solutions  with  the  targeting  officer 

•  Provides  predictive  TST  analysis  to  in  support  of  current  and  future  ISR  management  of 
sensors. 

•  Provides  support  to  the  MOC  TST  Ops  for  visualization  of  TST  event-related  activity  to 
include  predicted  enemy  courses  of  action  for  TST  support 

•  Reports  to:  XP  OPS. 

•  Specialty:  Intelligence  Officer  (04)  or  Air  Battle  Manager  with  recent  and  extensive 
C2ISR  background 

•  Workstation:  ADOCS,  SIPRNET  and  Collaboration  Application  (e.g.  mIRC) 

•  Links:  ADOCS,  SIPRNET  and  secure  telephone  (STU-III);  connectivity  to  onboard  and 
off-board  intelligence  support. 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

XP  Air  Operations  Officer  (position  XP  E2X) 

•  Facilitates  TST  execution  of  air  (Navy  and  Air  Force)  Strike  Assets. 

•  Coordinates  with  CVW  Strike  Operations  and  Joint  ISR  Officer 

•  Coordinates  with  Air  Force  Strike  LNO  and  Joint  /  Collation  Strike  Officers  (if 
embarked) 

•  Liaison  with  JFACC  CAOC  for  coordination  and  de-confliction  of  air  assets. 

•  Coordinates  with  JFN  ISR  Operations  for  TST  Target  Data  Refinement  and  Battle 
Damage  Assessment  (BDA)  and  Bomb  Hit  Assessment  (BHA) 

•  Coordinates  TST  sensor-to-shooter  operations 

•  Facilitates  TST  execution  of  ground  (e.g.  Marine,  Army)  Strike  Assets. 

•  Coordinates  with  Air  and  Surface/Submarine  Anchors 

Coordinates  ground  TST  sensor-to-shooter  operations 

•  Reports  to:  XP  OPS. 

•  Specialty:  CVW  experience,  senior  strike  aircrew  (04/5) 

•  Workstation:  ADOCS  workstation  on  SIPRNET  with  Collaboration  Application  (e.g. 
IWS)  application 

•  Links:  ADOCS,  SIPRNET  and  secure  telephone  (IP) 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

XP  Surface  Operations  Officer  (position  XP  DDX) 

•  Facilitates  TST  execution  of  surface  strike  assets. 

•  Coordinates  air  and  land  operations  with  JFMCC  and  JFACC. 

•  Coordinates  with  JFMCC  and  JFACC  for  current  air  and  surface  operations. 

•  Coordinates  Surface  TST  sensor-to-shooter  operations. 

•  Facilitates  TST  execution  of  ground  (e.g.  Marine,  Army)  Strike  Assets. 

•  Coordinates  ground  TST  sensor-to-shooter  operations. 

•  Reports  to:  XP  OPS 

•  Specialty:  tactical  strike  weapons  experience,  senior  tactically  qualified  officer 
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•  Workstation:  ADOCS  workstation  on  SIPRNET  with  Collaboration  Application  (e.g. 
IWS)  application. 

•  Links:  Access  to  ADOCS,  SIPRNET  and  secure  telephone  (STU-III) 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

XP  Coalition  Surface  Operations  Officer  (position  XP  ANZAC) 

•  Facilitates  TST  execution  of  coalitions  surface  strike  assets. 

•  Coordinates  coalition  air  and  land  operations  with  JFMCC  and  JFACC. 

•  Coordinates  with  JFMCC  and  JFACC  for  current  air  and  surface  operations. 

•  Coordinates  coalition  surface  TST  sensor-to-shooter  operations. 

•  Facilitates  TST  execution  of  coalition  ground  (e.g.  Marine,  Anny)  strike  assets. 

•  Coordinates  coalition  ground  TST  sensor-to-shooter  operations. 

•  Reports  to:  XP  OPS 

•  Specialty:  tactical  strike  weapons  experience,  senior  tactically  qualified  officer 

•  Workstation:  ADOCS  workstation  on  SIPRNET  with  Collaboration  Application  (e.g. 
IWS)  application. 

•  Links:  Access  to  ADOCS,  SIPRNET  and  secure  telephone  (STU-III) 

•  Engagement  Sequence  and  Notional  Data  Flow:  TBD 

Targeting  Officer  (position  TGT  OFF) 

•  Determines  which  available  ISR  asset  is  best  suited  to  address  the  emerging  or  “pop-up" 
potential  TST. 

•  Coordinates  dynamic  tasking  requests  with  ISR  Ops  Officer  in  support  of  JTF  and 
JFACC  TST  collection  opportunities  and  priorities. 

•  Maintains  liaison  with  JTF/JFACC  ISR  Operations  Officer(s)  for  dynamic  re-tasking 
requests  of  ISR  assets  not  under  direct  control. 

•  Accesses  available  IMINT,  SIGINT,  MASINT  and  other  ISR  raw  data  to  determine 
potential  TST’s  “detection”. 

•  Provide  targeting  guidance  to  Imagery  Screener  concerning  which  threat/s  to  screen  for 
based  on  available  intelligence  within  guidelines  of  JTF  and  JFACC  TST  targeting 
requirements. 

•  Inputs  target  nominations  manually  into  ADOCS  if  TES-N  feed  inoperable. 

•  Forwards  target  nomination  imagery  to  electronic  target  folders  (ETFs)  for  purposes  of 
experiment. 

•  Reviews  raw  and  finished  target  nomination  data  and  provides  TST  target  predictive 
analysis  to  TST  Ops  based  on  the  JTF  TST  Targeting  requirements  in  daily  intentions 
and  guidance  as  well  component  commanders’  TST  guidance.  If  so  elevates  target  to 
TST. 

•  Coordinates  with  JAOC  LNO  and  XP  ISR  contacts  to  keep  informed  of  potential  TSTs 
and  developing  details. 

•  Provides  input  for  positive  identification  (PID)  and  collateral  damage  estimates  (CDE) 
for  TSTs. 


203 


•  Assesses  BHA/BDA  and  will  control  BDA  block  in  ADOCS  for  BHA/BDA  imagery 
processed  by  or  provided  to  the  JIC. 

•  Provide  support  for  developing  SOP/TTP  to  manage  and  direct  7F  JIC  JFN  operations. 

•  Reports  to:  JFN  Operations  Officer. 

•  Specialty:  Intelligence  Officer  (03)  or  Targeting  Officer  experience 

•  Workstation:  ADOCS,  SIPRNET  and  Collaboration  Application  (e.g.  mIRC) 

Links:  ADOCS,  SIPRNET  and  secure  telephone  (IP);  connectivity  to  onboard 
and  off-board  intelligence  support. 
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Appendix  G  PROGRAM  OFFICE  SURVEY 


The  JFN  Program  Office  conducted  a  parallel  examination  of  JFN  performance  during  FGE- 
Kilo.  Part  of  that  study  was  a  survey  of  participants.  The  following  is  a  summary  of  the  results 
of  that  survey  and  the  survey  form.  This  information  was  provided  by  the  program  office 
participants. 

High-level  Analytical  Objective: 

Document  TES  functionality  and  products  in  the  IPB  process. 

Experimental  Issues: 

How  do  TES  products  contribute  to  the  IPB  process? 

Do  TES  products  enhance  predictive  analysis  of  enemy  course  of  action? 

Findings: 

This  analytical  objective  focused  on  the  process  and  configuration  of  TES,  GCCS-M  and 
ADOCS  as  they  relate  to  the  IPB  process  in  the  Joint  Intelligence  Center  (JIC).  Doctrinally,  IPB 
provides  a  systematic,  continuous  process  of  analyzing  the  threat  and  environment  in  a  specific 
geographic  area.  It  is  designed  to  support  staff  estimates  and  military  decision-making. 
Applying  the  IPB  process  helps  commanders  selectively  apply  and  maximize  his  combat  power 
at  critical  points  and  times  in  the  battle  space. 

The  JIC  intelligence  staff  was  surveyed  on  whether  the  JFN  enhanced  the  IPB  process  and  TST 
operations.  The  specific  focus  of  JFN  enhancements  was  TES.  There  were  certain  constraints 
to  the  experiment  that  may  have  influenced  their  opinion.  These  constraints  include  manning, 
training,  and  scenario  relevancy.  While  the  sample  was  small;  there  were  some  insights  that 
emerged. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  indicated  that  TES  aided  in 
identifying  gaps  in  the  commands  knowledge  of  the  threat  and  the  current  threat  situation. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  that  TES  products 
were  used  to  portray  threat  models  that  included  doctrinal  templates.  Additionally,  the  same 
percentages  were  reflected  in  the  respondents’  perception  of  TES  products  usefulness  in 
developing  models  that  depicts  threat  courses  of  action. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  on  ADOCS 
usefulness  in  providing  TST  operations  situational  awareness. 

25%  of  the  respondents  disagreed  and  75%  of  the  respondents  had  no  opinion  that  ADOCS 
provided  useful  infonnation  to  continuously  update  the  enemy  situation  template. 

All  respondents  agreed  or  strongly  agreed  that  there  was  effective  coordination  between  the  TES 


206 


imagery  screener,  the  ELINT  screener,  and  the  video  screener. 

All  respondents  agreed  that  the  imagery  analyst  processed  imagery  accurately  and  timely. 

50%  of  the  respondents  agreed  and  50%  of  the  respondents  had  no  opinion  that  the  configuration 
of  the  JFN  systems  in  the  JIC  was  sufficient  to  ensure  fusion  of  intelligence  was  accurate  and 
timely  for  targeting. 

25%  of  the  respondents  agreed  and  75%  of  the  respondents  had  no  opinion  that  JFN  provided  the 
tools  to  fuse  products  that  would  answer  the  commander’s  priority  intelligence  requirements. 

All  respondents  agreed  or  strongly  agreed  that  the  configuration  of  the  JFN  systems  in  the  JIC 
was  sufficient  to  facilitate  collaboration  between  different  functions. 

50%  of  the  respondents  disagreed  and  50%  of  the  respondents  had  no  opinion  that  track  elements 
on  the  TES  Integrated  Tactical  Display  (ITD)  were  the  same  as  the  GCCS-M  COP. 

66.66%  of  the  respondents  disagreed  and  33.33%  of  the  respondents  had  no  opinion  that 
ADOCS  and  JFN  systems  provided  situational  awareness  of  theater  wide  ISR  operations. 

75%  of  the  respondents  agreed  and  25%  of  the  respondents  had  no  opinion  that  the  JIC  provided 
targeting  data  to  the  JAOC  and  XP  to  support  TST  operations. 

All  of  the  respondents  disagreed  that  the  JFN  systems  were  technically  reliable. 

Conclusions: 

Several  constraints  to  the  data  collection  and  analysis  efforts  preclude  making  definitive 
conclusions.  These  constraints  include:  small  sample  size;  technical  difficulties;  control  of  the 
experimental  design;  and  adequate  manning.  However,  there  are  several  insights  that  can  be 
extracted  form  the  data. 

TES  capabilities  has  the  potential  to  contribute  to  the  IPB  process.  Noteworthy  was  TES 
contribution  to  portray  threat  models  that  included  doctrinal  templates,  and  their  usefulness  in 
developing  models  that  depicts  threat  courses  of  action. 

There  was  not  any  data  to  support  confidence  in  that  TES  and  GCCS-M  had  a  common  picture 
of  the  friendly  and  enemy  situation. 

There  were  indications  that  the  configuration  of  the  JIC  was  sufficient  to  ensure  that  capabilities 
of  different  systems  could  be  applied  to  fusion  of  intelligence  products. 

Technical  performance  was  a  significant  factor  the  limited  optimal  operational  capabilities. 
Questionnaire  on  Joint  Fires  Network  Enhancement  to  IPB  and 
Intelligence  Support  to  TST  Operations 
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1 .  TES  aided  in  identifying  gaps  in  the  command's  knowledge  of  the  threat  and  the  current  threat 
situation. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


2.  TES  products  were  used  to  portray  threat  models  that  included  doctrinal  templates  (which 
depict  how  the  threat  operates  when  unconstrained  by  the  effects  of  the  battlefield  environment). 
Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


3.  TES  products  were  helpful  in  developing  enemy  COA  models  that  depict  the  threat's 
available  CO  As. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


4.  ADOCS  capability  to  provide  TST  operations  situational  awareness  was  useful  during  the 
IPB  process. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


5.  ADOCS  capability  provided  me  sufficient  information  to  continuously  update  the  enemy 
situation  template. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 
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Comments: 


6.  There  was  effective  coordination  between  the  TES  imagery  screener,  the  ELINT  screener, 
and  the  video  screener. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


7.  The  track  elements  of  the  TES  Integrated  Tactical  Display  were  the  same  as  GCCS.M  COP. 
Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


8.  ISR  planning  supported  TST  operations. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


9.  The  TES  Mission  Planner  was  useful  in  planning  and  synchronizing  theater  and  national  ISR 
assets  for  TST  operations. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


1 .  ADOCS  and  JFN  systems  provided  situational  awareness  of  theater  wide  ISR  operations. 
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Strongly  Disagree  Disagree  Neutral 


Agree 


Strongly  Agree 


Comments: 


2.  The  imagery  analyst  processed  imagery  accurately  and  timely. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


3.  The  JIC  provided  targeting  data  to  the  JAOC  and  XP  to  support  TST  operations. 
Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


4.  The  JISE  chief  was  able  to  timely  fuse  infonnation  from  the  targeting  officer  and  collection 
manager  in  order  to  make  re-strike  recommendations  to  the  JAOC. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


5.  The  electronic  target  folders  (ETF)  were  useful  to  the  IPB  process. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 
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6.  The  senior  intelligence  officer  in  the  JAOC  had  the  same  enemy  COP  as  the  JIC. 
Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


7.  JFN  including  ADOCS  provided  the  capability  to  distribute  intelligence  infonnation  that  was 
accurate  and  timely. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


8.  The  JIC,  JAOC  and  subordinate  units  had  a  common  picture  of  the  enemy. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


9.  Configuration  of  the  JFN  systems  in  the  JIC  was  sufficient  to  facilitate  collaboration  between 
different  functions. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: _ 


10.  Configuration  of  the  JFN  systems  in  the  JIC  was  sufficient  to  ensure  fusion  of  intelligence 
was  timely  and  accurate  for  targeting. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 
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Comments: 


11.  JFN  provided  the  tools  to  fuse  products  that  would  answer  the  commander’s  priority 
intelligence  requirements. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


12.  JFN  gave  provided  the  capability  to  better  synchronize  theater  and  tactical  ISR  plans  to 
support  targeting. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


13.  JFN  provide  the  capability  to  better  dynamically  re -task  sensors  to  support  targeting  and  IPB. 
Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


14.  JFN  systems  and  ADOCS  were  generally  reliable  (i.e.,  outages,  network  problems,  data  base 
access,  etc). 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 


15.  Collaborative  tools  were  sufficient  to  coordinate  events. 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

Comments: 
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Appendix  H  CPX  PRINCIPAL  RESULTS  AND  RECOMMENDATIONS 


This  Appendix  contains  the  Recommendations  and  Principal  Results  from  the  Command  Post 
Exercise  (CPX)  portion  of  FBE-Kilo.  Many  of  these  results  and  recommendations  also  apply  to 
FTX.  Those  that  do  directly  apply  are  also  included  in  Section  6.2,  Principal  Conclusions  and 
Recommendations,  of  this  report. 
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H.l  CPX  PRINCIPAL  RESULTS 


FBE-Kilo,  Command  Post  Exercise  Phase 

PR  #1  -  Achievement  of  SOP  Testing  Objective 

•  Experimentation  difficulties  prevented  an  adequate  determination, 
o  No  manning  of  JFACC  Afloat. 

o  Lack  of  JAOC  manning, 

o  TES-N  operators  lack  of  training. 

•  CPX  was  modified  to  be  mostly  training  for  FTX. 

This  initiative  was  to  test  JFN  support  for  TST,  and  the  associated  SOP,  for  operations  in  the 
three  roles  for  which  it  will  be  employed  by  C7F: 

as  an  embarked  CJTF  with  other  supported  staff(s)  embarked, 
as  an  embarked  JFMCC/NAVFOR,  and 

as  the  Fleet  JFN/JFN  supporting  deployed  RTCs  and  RTC  Lites. 

Key  equipment  components  were  an  afloat  JFN  (supporting  the  JTF  staff  and  a  JFACC  forward) 
and  an  ISR-M  supporting  the  JFACC  Main. 

Key  participants  include  the  entire  CJTF  command  structure  and  Component  Commanders. 
JFACC  participation  was  essential  to  meet  the  majority  of  objectives  in  addition  to  supporting 
examination  of  USAF  ISR  Manager  (ISRM)  to  JFN  operations. 

The  CPX  was  the  only  time  during  TT03  that  full  CJTF  manning  was  to  be  in  place,  which  is 
necessary  to  validate  the  CONOPS  and  associated  standing  procedures. 

Not  having  a  manned  JFACC  Afloat  eliminated  a  major  component  of  SOP  testing  that  was  to  be 
accomplished.  JAOC  personnel  shortage  also  had  a  detrimental  effect  on  exercising  the  SOP. 

With  one  exception,  personnel  in  the  JIC  had  no  experience  with  TES-N.  The  result  was  that  a 
major  portion  of  CPX  was  devoted  to  training  rather  than  initiative  experimentation. 

Equipment  difficulties  also  played  a  major  role  in  reducing  the  ability  to  obtain  results  for  this 
initiative  (see  PR  #2). 

The  basic  objectives  of  this  initiative  could  not  be  met.  Indications  of  needed  SOP  development 
for  a  JIC,  if  it  is  to  participate  in  TST,  were  determined. 

FBE-Kilo,  Command  Post  Exercise  Phase 

PR  #2  -  Achievement  of  JFN  Contributions  to  TST  Objective 

•  No  baseline  without  JFN  available  eannot  nerform  an  afienuate  test 


The  stated  JFN  objective  was  to  determine  the  contribution  of  JFN  to  TST  prosecution.  In  order 
to  determine  JFN-unique  contributions,  or  synergistic  JFN  effects,  a  baseline  of  perfonnance 
without  JFN  is  needed.  Such  a  baseline  requires  using  the  same  C2  structure  and  infonnation 
processes  as  were  used  in  the  experiment.  Baseline  infonnation  is  not  available. 

Equipment  problems  prevented  testing  end-to-end  JFN  performance.  Target  nominations  could 
not  be  passed  directly  from  TES-N  to  ADOCS,  or  directly  to  ISRM.  FBEnet  was  not  operational 
due  to  Ku  Band  switching  problems  in  Hawaii.  The  result  was  that  many  information  paths  that 
are  crucial  for  realizing  JFN  potential  were  not  operational. 

Because  of  the  collection  of  equipment  and  manning  problems  the  only  comprehensive  test  of 
JFN  that  could  be  made  was  of  the  TES-N  component  in  the  JIC. 

The  basic  objectives  of  this  initiative  could  not  be  met.  Results  that  could  be  derived  are 
indications  of  JFN  potential  for  TST  processes  within  a  JIC. 
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FBE-Kilo,  Command  Post  Exercise  Phase 
PR  #3  -  TES-N  Capabilities 

•  Works  well  for  IMINT  exploitation. 

o  Video  screener  a  major  factor  in  closing  TST  timeline, 
o  Directing  tactical  imagery  assets. 

•  Inability  to  drop  validated  aim  points  a  major  drawback. 

•  Improved  sensor  control  by  image  analyst  required. 


Image  analysis  and  processing  worked  well,  essentially  creating/producing  an  efficient  assembly 
line.  Operators,  with  little  training,  were  able  to  explore  images  and  make  both  analysis  and 
processing  decisions  fairly  quickly.  (Difficulties  encountered  because  of  the  simulation  are 
covered  in  a  subsequent  Principal  Result.) 

An  important  capability  was  for  the  image  analyst  to  be  able  to  direct  tactical  sensors.  The 
analyst  worked  through  a  sensor  manager  and  the  process  worked  moderately  well.  There  were 
difficulties  with  this  sensor  control,  as  implemented,  in  that  there  was  no  direct  provision  for 
sensor  control  at  the  analyst's  terminal.  A  direct  link  that  the  analyst  can  use  without 
interrupting,  nor  losing  sight  of,  imagery  is  needed. 

There  were  problems  with  imagery  infonnation  content.  Transmission  of  aim  points  and  Lat- 
Long  needs  to  be  improved.  This  was  done  verbally  or  by  notes,  which  slowed  the  process. 
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FBE-Kilo,  Command  Post  Exercise  Phase 
PR  #4  -  TES-N  Personnel  Issues 

•  Only  the  team  leader  was  an  experienced  operator. 

o  Lack  of  operator  training  hindered  TST  operations. 

•  New  operators  learned  very  fast. 

o  Performed  quite  well  with  minimal  training. 

o  Could  determine  whether  performance  difficulties  were  due  to 
equipment  or  training. 

•  New  operators  did  not  understand  full  spectrum  of  TST  process. 


The  TES-N  team  leader  in  the  JIC  was  an  IS  1  who  had  9  months  of  intensive  experience  with  the 
system.  He  was  the  trainer  for  a  team  of  three  Sailors  who  had  no  experience  or  training  on  the 
system.  On-the-job  training  was  performed  during  the  experiment.  It  is  to  be  expected  that  the 
performance  of  well-trained  operators  would  be  better  than  those  in  the  midst  of  training  and  that 
this  had  an  impact  on  TST  processes.  It  was  not  possible  to  determine  which  process 
performance  difficulties  were  the  result  of  an  operator  lacking  proficiency  or  due  to  JFN 
capability  difficulties. 

It  was  surprising  how  fast  the  new  operators  learned  how  to  use  TES-N.  They  were  perfonning 
image  analysis  and  TST  nominations  within  a  few  hours  of  developing  familiarity  with  the 
system.  This  speaks  well  for  the  performance  to  be  expected  with  JFN. 

Operator  perfonnance  was  hindered  by  their  learning  only  that  portion  of  the  TST  process  they 
were  performing.  Performance  will  improve  when  operators  understand  the  full  process  and 
how  the  functions  at  the  node  they  are  working  fits  into  the  overall  process. 
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FBE-Kilo,  Command  Post  Exercise  Phase 
PR  #5  -  Operator’s  Acceptance  of  TES-N 

•  In  spite  of  lack  of  familiarity,  operators  recognized  the  system’s  potential 
for  improving  performance  and  efficiency 

•  User-friendly  and  easy  to  leam. 

•  Much  appreciation  of  several  functions  combined  in  one  machine. 


With  the  exception  of  the  team  leader,  the  TES-N  operators  were  totally  unfamiliar  with  the 
system  and  with  TST  processes.  Their  training  was  on  IPB  processes.  Thus,  they  were  being 
introduced  to  both  a  new  system  and  a  new  process.  In  spite  of  this  they  were  enthusiastic  about 


TES-N. 


They  felt  the  system  was  easy  to  learn  and  that  the  graphical  user  interface  (GUI)  layout  and 
methods  of  use  were  fairly  intuitive. 

The  system  layout  was  such  that  a  terminal  could  be  used  for  image  screening,  image  analysis,  or 
nomination.  This  allowed  those  operations  to  be  exchanged  or  shared.  Having  multiple 
functions  resident  within  one  machine  produced  manpower  savings  as  a  result  of  increased  work 
efficiency  and  direct  sharing  of  information  between  operators. 
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FBE-Kilo,  Command  Post  Exercise  Phase 

PR  #6  -  TES-N  Training  Issues 

•  Current  simulation  hinders  training. 

o  Lack  of  reality  interfered  with  all  aspects  of  training  and  performance, 
o  Simulation  designed  specifically  for  TES-N  training  needed. 

•  Operators  need  broad  TST  process  training. 


CPX  was  used  to  provide  TES-N  operator  training  in  an  operational  context.  But,  the  simulation 
used  for  the  experiment  presented  unrealistic  renderings  of  battlefield  objects.  This  lack  of 
realism  interfered  with  operator  performance  and  therefore  with  their  training.  In  addition  to  low 
fidelity,  the  presentation  of  the  battlefield  was  such  that  image  analysts  could  not  distinguish 
different  instances  of  the  same  object  type.  This  produced  a  situation  where  operators  were 
moving  back  and  forth  between  objects  to  figure  out  which  was  which,  interfering  with  training. 


A  realistic  simulation  designed  specifically  for  TES-N  training  is  needed. 

Operators  did  not  have  an  understanding  of  the  TST  process.  Training  on  the  TST  process  was 
being  conducted  at  the  same  time  as  how  to  do  it.  Training  on  the  full  TST  process  is  needed  as 
a  prerequisite  to  system  "knobology"  training. 
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FBE-Kilo,  Command  Post  Exercise  Phase 
PR  #7  -  Experimentation  Issues 

•  Experiment  and  Exercise  were  decoupled. 

•  Greater  emphasis  needed  on  learning  spirals  prior  to  operational  field 
experimentation. 

•  Complete  exercising  of  equipment  and  validation  of  functions  required 
prior  to  operational  field  experimentation. 


The  exercise  proceeded  through  the  MSEL  events  in  good  fashion.  Due  to  a  number  of  factors 
mentioned  earlier  it  was  not  possible  for  the  experiment  to  proceed  in  the  same  fashion.  The 
result  was  that  the  two  became  decoupled.  It  was  not  clear  that  it  was  planned  for  the  exercise  to 
depend  on  infonnation  coming  out  of  TES-N  in  the  JIC,  but  in  execution  it  did  not.  Thus,  the 
experiment  became  one  that  could  have  been  perfonned  anywhere.  A  shipboard  operation  and  a 
real  operational  environment  were  not  needed  nor  used. 

This  brings  into  question  the  wisdom  of  having  operational  field  experiments  be  a  principal 
information  collection  means.  Savings  could  be  realized  if  Navy  experimentation  were  to 
concentrate  on  learning  spirals  and  having  operational  field  experimentation  done  only  when 
necessary  to  validate  results  in  an  operational  environment. 

CPX  suffered  significantly  from  not  having  equipment  operate  properly.  A  process  is  needed 
where  an  experiment  is  not  undertaken  until  equipment  has  been  fully  tested,  determined  to  be 
functioning  properly,  and  warranted  to  be  ready  to  fully  support  the  experiment's  objectives. 
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FBE-Kilo,  Command  Post  Exercise  Phase 
PR  #8  -  Fleet  Follow-Up 

•  Little  Fleet  follow-up  has  occurred  after  former  FBEs. 
o  Operational  improvements  have  been  lost. 

o  Fleet  recommendations  for  program  improvement  have  not  occurred. 

•  FBE-K  opportunities, 
o  TSTSOP 

o  Design  of  Fleet  Flagship  as  a  JFN  TST  hub. 
o  TST  processes  and  SOP  for  less  well-equipped  units. 


The  pace  of  FBEs  fonnerly  has  been  such  that  the  planning  for  the  next  experiment  is  underway 
before  the  current  one  is  concluded,  certainly  before  analysis  is  completed.  This  has  prevented 
lessons-learned  from  being  carried  forward  to  the  next  experiment.  It  has  also  precluded 
investing  the  effort  needed  to  follow  up  with  the  Fleet  on  system  and  process  improvements. 
Much  of  the  possible  immediate  value  of  FBE  results  has  not  been  realized. 

FBE-K,  even  the  CPX  portion,  present  opportunities  for  Fleet  follow-up.  Areas  that  have  been 
identified  as  fruitful  for  doing  this  are: 

Development  of  TST  SOP  for  an  afloat  CJTF 

Design  of  the  processes  for  a  Fleet  Flagship  to  function  as  a  JFN  TST  hub. 

Developing  TST  processes  and  SOP  for  less  well-equipped  ships/units. 

Undertaking  these  suggested  Fleet  follow-up  items  will  require  a  shift  of  funds  and  manpower  to 
this  activity. 
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H.2  CPX  RECOMMENDATIONS 


H.2.1  FLEET  FOLLOW-UP 

Fleet  Battle  Experiments  have  two  purposes:  (1)  to  advance  and  improve  the  capabilities  of 
systems  and  processes,  and  (2)  to  move  new  operational  capabilities  to  Navy  operating  units. 

Part  of  the  reason  for  doing  number  one  with  operational  units  is  that,  at  some  point,  capabilities 
testing  must  be  done  in  a  realistic,  human-in-the-loop  environment.  Part  of  the  reason  for  a  Fleet 
participating  in  an  experiment  is  to  improve  capabilities  and  the  ensuing  "leave-behinds"  that  can 
occur.  Leave-behinds  are  not  only  equipment  but  also  new  or  improved  processes. 

To  date,  most  leave-behinds  have  been  transitory  rather  than  permanent  improvements.  A  telling 
example  was  a  comment  made  by  VADM  Metzger,  then  C7F,  during  an  FBE  presentation: 

"What  happened  to  the  processes  we  put  in  place  following  Delta?"  The  answer  was  that  they 
had  disappeared  due  to  staff  changes.  The  basic  problem  was  that  there  was  no  process  or 
program  to  make  the  changes  permanent. 

It  is  recommended  that  NWDC  institute  a  process  with  Seventh  Fleet  to  take  the  results  from 
FBE-K  and  develop  TST  CONOPS  and  TTPs,  in  partnership  with  the  Fleet,  that  will  be  adopted 
by  the  Fleet.  Results  from  CPX  indicate  that  follow-on  development  would  most  profitably  be  in 
the  following  areas: 

1.  Development  of  TST  CONOPS  and  TTPs  for  a  BLUE  RIDGE  CJTF. 

2.  Develop  a  concept  for  BLUE  RIDGE  as  a  hub  for  TST  information. 

3.  Following  the  hub  concept,  specify  what  systems  are  needed  for  the  range 
of  users  included  in  the  network,  including  "disadvantaged"  users. 

4.  Develop  procedures  and  guidelines  for  TST  operations  for  all  users, 
including  situations  when  full  JFN  capabilities  are  not  available, 

or  completely  unavailable. 

Adopting  this  recommendation  will  entail  a  significant  shift  in  the  way  NWDC  does  business. 

To  date,  personnel  have  ceased  involvement  with  an  FBE  once  it  is  completed,  moving  on  to  the 
next  event.  Following  this  recommendation  means  that  personnel  would  continue  to  work  on  the 
initiatives  associated  with  an  experiment  for  some  time  after  it  is  physically  completed.  This 
requires  a  shift  of  resources  to  the  follow-up  aspect  of  an  experiment.  It  is  believed  that  doing  so 
will  produce  a  significant  improvement  in  NWDC  productivity  as  well  as  produce  an  overall  cost 
savings  to  the  Navy. 


H.2.2  EXPERIMENTATION  STRUCTURE 

Operational  field  experiments  are  expensive,  both  in  terms  of  real  fund  expenditures  and  in  terms 
of  the  use  of  platforms  and  their  personnel.  Field  experimentation  as  the  primary  data 
acquisition  means  is  not  cost  effective.  Also,  experience  has  shown  that  it  is  not  possible  to 
produce  quality  results  when  there  is  an  overlap  between  analysis  for  one  experiment  and 
planning  for  the  next.  With  such  overlap,  lessons  learned  do  not  carry  over  into  improvements 


223 


for  the  next  event. 


Another  problem  involved  the  mechanics  of  having  a  "learning"  experiment  overlaid  on  a  Fleet 
exercise.  There  is  a  basic  incompatibility.  Instead,  one  should  have  preliminary  learning  occur 
before  going  into  the  field  then  an  exercise  used  for  human-in-the-loop  and  operational  testing  to 
ensure  validity.  Using  this  approach  will  allow  for  tighter  coupling  between  experiment  and 
exercise  objectives.  The  goals  of  the  exercise  will  always  be  primary  and  one  can  adapt  the 
experiment  to  those  goals  and  produce  high  quality  results  that  are  directly  applicable  to  the 
Fleet. 

It  is  recommended  that  a  series  of  appropriate  studies  be  performed  to  meet  learning  objectives, 
including  workshops  and  even  laboratory  experiments.  Going  into  the  field  would  occur  only 
when  needed  for  validation.  Hence,  FBEs  would  not  be  events  that  occur  on  a  regular  schedule, 
and  perhaps  not  exist  in  their  current  form.  Rather,  when  a  particular  study  area  progressed  to 
the  point  of  needing  to  do  so,  an  appropriate  venue  for  operational  field-testing  would  be  sought. 
This  could  be  identified  as  an  LOE,  a  culmination  event,  or  whatever  would  be  appropriate. 


H.2.3  EXPERIMENTATION  HARDWARE 

The  experience  in  past  Fleet  Battle  Experiments  has  been  that  there  were  always  some 
equipment  problems.  Perhaps  this  is  to  be  expected,  but  it  should  be  on  a  minor  scale  and  the 
type  of  problem  that  can  be  quickly  remedied.  FBE-K  CPX  was  perhaps  the  worst  situation 
encountered  over  the  FBE  series,  with  major  equipment  problems  significantly  disrupting  the 
Fires  Initiative. 

A  policy  is  needed  where  equipment  and  interfaces  must  be  fully  tested  and  functionality 
ensured  prior  to  an  experiment.  A  limited  objective  experiment  (LOE)  devoted  to  equipment 
testing  is  recommended.  This  may  be  costly,  but  not  be  as  costly  as  losing  large  portions  of  the 
desired  results  during  a  Fleet  Battle  Experiment. 


H.2.4  EXPERIMENTATION  DATA 

Three  types  of  data  are  typically  obtained  during  an  operational  field  experiment:  (1)  subjective 
opinions  about  the  perfonnance  of  systems  and  processes,  (2)  subject  matter  experts  logging 
event  observations,  and  (3)  electronic  data  logged  within  and  between  hardware  systems.  The 
latter  type  includes  simulation  data. 

Planning  an  experiment  requires  close  coupling  between  the  detailed  goals  of  an  initiative  and 
data  elements  to  be  captured.  Analysis  of  an  experiment  requires  complete  sets  of  all  three  types 
of  data  so  that  event  chains  can  be  reconstructed  and  the  context  within  which  events  occurred 
can  be  fully  understood.  A  missing  data  element,  or  link,  in  the  event  chain  breaks  it  and 
detracts  from  the  ability  to  fully  understand  what  occurred  and  why.  Absent  context  means 
cause-and-effect  relationships  cannot  be  established. 
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To  date  it  has  not  been  possible  to  obtain  all  of  the  needed  electronic  data.  Part  of  the  reason  for 
this  is  that  doing  so  is  expensive  and  funds  have  not  been  made  available.  The  recommendation 
is  made  that  the  lists  of  electronic  data  requirements  that  have  been  provided  be  prioritized, 
decisions  made  as  to  which  data  will  be  obtained,  system  owners  directed  to  obtain  the  data  and 
make  it  available  for  analysis,  and  that  adequate  funding  be  provided  for  the  purpose.  In 
addition,  impact  statements  should  be  developed  for  those  cases  where  the  data  will  not  be 
available  and  deficiencies  be  taken  into  account  in  experiment  planning. 


H.2.5  EXPERIMENT  PLANNING  STABILITY 

CPX  was  an  unusual  situation  in  that  there  were  major  changes  in  the  experiment  structure  (e.g. 
lack  of  a  JFACC  Forward)  shortly  before  the  experiment,  and  then  personnel  shortfalls  due  to 
BLUE  RIDGE  departing  early  for  the  typhoon.  However,  it  is  not  unusual  in  FBEs  to  have 
equipment  and  process  changes  occur  right  up  to  the  beginning  of  an  experiment.  Such  changes 
disrupt  data  capture  and  analysis  plans  and  can  even  make  it  impossible  to  capture  data  required 
to  meet  Initiative  objectives. 

It  is  recommended  that  an  experiment  be  "locked  down"  four  months  prior  to  its  start.  An 
exception  would  be  when  there  is  a  series  of  events  that  includes  an  equipment  testing  LOE  prior 
to  the  field  experiment.  In  this  case,  the  LOE  should  occur  six  weeks  prior  to  the  operational 
experiment  and  the  lock-down  occur  within  one  week  after  the  LOE. 


H.2.6  SIMULATION  AND  TRAINING 

CPX  was  different  from  previous  FBEs  in  that  it  had  a  definite  training  aspect  associated  with 
JFN  and  SOP  evaluation.  The  stated  purpose  of  the  evaluations  was  that  they  be  conducted  for  a 
particular  C2  configuration  and  operational  situation.  Training  was  to  be  conducted  using  TES- 
N  to  prosecute  TSTs.  The  operational  situation  was  to  be  created  by  simulation.  Training  and 
evaluation  were  significantly  negatively  affected  by  the  simulation's  lack  of  fidelity. 

It  is  recommended  that  realistic  training  modules  be  developed  for  TES-N  and  JFN.  This  could 
be  done  with  pre-recorded  real  imagery  and  preset  scenarios  as  is  done  for  other  systems. 
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One  copy  each  to  the  following  organizations: 

COMFLTF ORCOM  //01//N5B/N6/N8/N82// 

CNO  WASHINGTON  DC//01/N2/N3/N6/N7/N8/N61/N614/N70/N74/N75/76/N77/N78// 
USCINCJFCOM  //J9// 

COMPACFLT  //N6/N30E/N39// 

COMLANTFLT 
CINCUSNAVEUR 
COMU  SNA  V  CENT 

ASSTSECNAV  RDA  WASHINGTON  DC 

COMSECONDFLT 

COMTHIRDFLT 

COMFIFTHFLT 

COMSIXTHFLT 

COMSEVENTHFLT 

COMNAVAIRFOR 

COMNA  V  SURF  OR 
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COMNA  V  SUBF  OR 

COMNAVNETWARCOM  //01/N60/N8// 

COMNA  V  SURFLANT 
COMNA  V  SURFP  AC 
COMNA  VAIRPAC 
COMNA  VAIRLANT 
COMSUBPAC 
NAVWARCOL  //CNWS// 

COMCARGRU  ONE 
COMCARGRU  TWO 
COMCARGRU  THREE 
COMCARGRU  FOUR 
COMCARGRU  FIVE 
COMCARGRU  SIX 
COMCARGRU  SEVEN 
COMCARGRU  EIGHT 
COMCRUDESGRU  ONE 
COMCRUDESGRU  TWO 
COMCRUDESGRU  THREE 
COMCRUDESGRU  FIVE 
COMCRUDESGRU  EIGHT 
COMCRUDESGRU  TWELVE 
COMSUBGRU  TWO 
COMSUBGRU  SEVEN 
COMSUBGRU  EIGHT 
COMSUBGRU  NINE 
COMPHIBGRU  ONE 
COMPHIBGRU  ONE 
COMPHIBGRU  TWO 
COMPHIBGRU  THREE 
COMNA VBEACHGRU  TWO 
COMNA V SECGRU  //N5// 

COMNA  VNETSPAOPSCOM 

COMSPAWARSYSCOM 

COMNAVSEASYSCOM 

COMNA VAIRSYSCOM  PATUXENT  RIVER  MD 

SPAWARSYSCEN  SAN  DIEGO 

COMNA  V  SPEC  WARCOM 

COMNAVSPECWARDEVGRU  DAM  NECK 

COMINEWARCOM  //N6/N8// 

NAVSTKAIRWARCEN 

COMSURFWARDEVGRU  LITTLE  CREEK 

COMSUBDEVRON  TWELVE 

COMOPTE  VF  OR 

CNR 
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FLTINF  O  WARCEN 

FLTINF O WARCEN  DET  SAN  DIEGO 

NAVINFOWARACT  FT  GEORGE  G  MEADE  //00// 

NCTF-CND  WASHINGTON  DC 
NAVSECGRUACT  PENSACOLA 
NAVSECGRUACT  WHIDBEY  ISLAND  WA 
NAVUNSEAWARCENDIV  NEWPORT  RI 
NAVAIRWARCENWPNDIV  PT  MUGU 
COMNAVAIRWARCENWPNDIV  CHINA  LAKE 
TACTRAGRUPAC  SAN  DIEGO 
SWOSCOLCOM  NEWPORT 
EWTGPAC 
FCTCPAC 

NAVPGSCOL  MONTEREY  //Knox  Library//Meyer  Institute//Research  Office// 
NRL  WASHINGTON 
CG  I  MEF 
CG  MCCDC 

ACC  CG  LANGLEY  AFB  VA 
ESC  HANSCOM  AFB  MA 

CDR  TRADOC  DATA  PROC  FLDOFC  FT  MONROE  VA 
NA VWARDEVCOM  DET  NORFOLK 
NA VWARDEVCOM  DET  SAN  DIEGO 
CTF  12 

COMPHIBRON  ONE 
COMDESRON  NINE 
COMCARAIRWING  ELEVEN 
COMCARAIRWING  NINE 
COMCMRON  THREE 
USS  FITZGERALD 
USS  BENFOLD 
USS  SALT  LAKE  CITY 
USS  CORONADO 
USS  BOXER 
USS  ANTIETAM 

JOINT  VENTURE  HSV  XRAY  ONE 
TSC  NORTH  ISLAND  CA 
FACSFAC  DET  SCORE  SAN  DIEGO 
COMSUBRON  ELEVEN 
AIRTEVRON  ONE 
COMEODGRU  ONE 
COMEODGRU  TWO 
EODMU  THREE 
EODGRU  ONE  VSW  MCM  DET 
EODMU  SEVEN 
COMNAVSPECWARGRU  ONE 
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COMHSLWINGPAC  SAN  DIEGO 

AIRTEVRON  NINE  CHINA  LAKE 

CARAEWRON  ONE  ONE  TWO 

COMAE WWINGP AC  POINT  MUGU 

FLECOMPRON  SIX  DET  PATUXENT  RIVER 

FLECOMPRON  SIX 

PATRON  FOUR  SIX 

PATRON  NINE 

SEACONRON  THREE  THREE 

SPEC  PROJ  PATRON  TWO  KANEOHE  BAY 

NAVOCEANO  STENNIS  SPACE  CENTER 

NA V SURFWARCEN  COASTSYSTA  PANAMA  CITY 

COMNAVMETOCCOM  STENNIS  SPACE  CENTER 

FLENUMMETOCCEN  MONTEREY 

NAVPACMETOCCEN  SAN  DIEGO 

VAQRON  ONE  THREE  SEVEN 

NMITC  DAM  NECK 

DARPA  //AT  O/IT  0/ OPX// 

PEO  SHIPS 
PEO  IWS 

PEO  C4I  &  SPACE 
PEO  IT 

PEO  LITTORAL  &  MINE  WARFARE 
PEO  SUBMARINES 
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